Menentukan pekerjaan di alur Anda

Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019

Anda dapat mengatur alur Anda ke dalam pekerjaan. Setiap alur memiliki setidaknya satu pekerjaan. Pekerjaan adalah serangkaian langkah yang berjalan secara berurutan sebagai unit. Dengan kata lain, pekerjaan adalah unit kerja terkecil yang dapat dijadwalkan untuk dijalankan.

Untuk mempelajari tentang konsep dan komponen utama yang membentuk alur, lihat Konsep utama untuk pengguna Azure Pipelines baru.

Azure Pipelines tidak mendukung prioritas pekerjaan untuk alur YAML. Untuk mengontrol kapan pekerjaan berjalan, Anda dapat menentukan kondisi dan dependensi.

Menentukan satu pekerjaan

YAML

Dalam kasus paling sederhana, alur memiliki satu pekerjaan. Dalam hal ini, Anda tidak perlu secara eksplisit menggunakan job kata kunci kecuali Anda menggunakan templat. Anda dapat langsung menentukan langkah-langkah dalam file YAML Anda.

File YAML ini memiliki pekerjaan yang berjalan pada agen dan output Hello worldyang dihosting Microsoft.

pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

Anda mungkin ingin menentukan lebih banyak properti pada pekerjaan tersebut. Dalam hal ini, Anda dapat menggunakan job kata kunci.

jobs:
- job: myJob
  timeoutInMinutes: 10
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - bash: echo "Hello world"

Alur Anda bisa memiliki beberapa pekerjaan. Dalam hal ini, gunakan jobs kata kunci.

jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

Alur Anda mungkin memiliki beberapa tahap, masing-masing dengan beberapa pekerjaan. Dalam hal ini, gunakan stages kata kunci.

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

Sintaks lengkap untuk menentukan pekerjaan adalah:

- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  strategy:
    parallel: # parallel strategy
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  timeoutInMinutes: number # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
  variables: { string: string } | [ variable | variableReference ] 
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container
  uses: # Any resources (repos or pools) required by this job that are not already referenced
    repositories: [ string ] # Repository references to Azure Git repositories
    pools: [ string ] # Pool names, typically when using a matrix strategy for the job

Jika niat utama pekerjaan Anda adalah untuk menyebarkan aplikasi Anda (dibandingkan dengan membangun atau menguji aplikasi Anda), maka Anda dapat menggunakan jenis pekerjaan khusus yang disebut pekerjaan penyebaran.

Sintaks untuk pekerjaan penyebaran adalah:

- deployment: string        # instead of job keyword, use deployment keyword
  pool:
    name: string
    demands: string | [ string ]
  environment: string
  strategy:
    runOnce:
      deploy:
        steps:
        - script: echo Hi!

Meskipun Anda dapat menambahkan langkah-langkah untuk tugas penyebaran dalam job, kami sarankan Anda menggunakan pekerjaan penyebaran. Pekerjaan penyebaran memiliki beberapa manfaat. Misalnya, Anda dapat menyebarkan ke lingkungan, yang mencakup manfaat seperti dapat melihat riwayat apa yang telah Anda sebarkan.

Klasik

Untuk menambahkan pekerjaan ke alur build Anda, edit alur di halaman Alur. Pilih ... untuk menambahkan pekerjaan.

Untuk menambahkan pekerjaan ke alur rilis Anda, edit alur dari Rilis> Alur. Lihat tugas tahap di tahap tempat Anda ingin menambahkan pekerjaan Anda. Pilih ... untuk menambahkan pekerjaan.

Jenis pekerjaan

Pekerjaan dapat dari berbagai jenis, tergantung di mana mereka berjalan.

YAML

• Pekerjaan kumpulan agen berjalan pada agen di kumpulan agen.
• Pekerjaan server berjalan pada Azure DevOps Server.
• Pekerjaan kontainer dijalankan dalam kontainer pada agen di kumpulan agen. Untuk informasi selengkapnya tentang memilih kontainer, lihat Menentukan pekerjaan kontainer.

Klasik

• Pekerjaan kumpulan agen berjalan pada agen di kumpulan agen.
• Pekerjaan server berjalan pada Azure DevOps Server.
• Pekerjaan grup penyebaran berjalan pada mesin dalam grup penyebaran. Pekerjaan ini hanya tersedia dalam alur rilis. Untuk informasi selengkapnya tentang menentukan grup server target untuk penyebaran, lihat Pekerjaan grup penyebaran.

Pekerjaan kumpulan agen

Ini adalah jenis pekerjaan yang paling umum dan dijalankan pada agen di kumpulan agen.

• Saat menggunakan agen yang dihosting Microsoft, setiap pekerjaan dalam alur mendapatkan agen baru.
• Gunakan tuntutan dengan agen yang dihost sendiri untuk menentukan kemampuan apa yang harus dimiliki agen untuk menjalankan pekerjaan Anda. Anda mungkin mendapatkan agen yang sama untuk pekerjaan berturut-turut, tergantung pada apakah ada lebih dari satu agen di kumpulan agen Anda yang sesuai dengan permintaan alur Anda. Jika hanya ada satu agen di kumpulan Anda yang cocok dengan permintaan alur, alur menunggu hingga agen ini tersedia.

Catatan

Tuntutan dan kemampuan dirancang untuk digunakan dengan agen yang dihost sendiri sehingga pekerjaan dapat dicocokkan dengan agen yang memenuhi persyaratan pekerjaan. Saat menggunakan agen yang dihosting Microsoft, Anda memilih gambar untuk agen yang cocok dengan persyaratan pekerjaan, jadi meskipun dimungkinkan untuk menambahkan kemampuan ke agen yang dihosting Microsoft, Anda tidak perlu menggunakan kemampuan dengan agen yang dihosting Microsoft.

YAML

pool:
  name: myPrivateAgents    # your job runs on an agent in this pool
  demands: agent.os -equals Windows_NT    # the agent must have this capability to run the job
steps:
- script: echo hello world

Atau beberapa tuntutan:

pool:
  name: myPrivateAgents
  demands:
  - agent.os -equals Darwin
  - anotherCapability -equals somethingElse
steps:
- script: echo hello world

Klasik

Anda memiliki opsi untuk menentukan permintaan dalam alur, dalam pekerjaan, atau keduanya. Jika Anda menentukan tuntutan dalam alur dan dalam pekerjaan, penyatuan dua set tuntutan diperlukan agar sistem memilih agen.

Pelajari selengkapnya tentang kemampuan agen.

Pekerjaan server

Tugas dalam pekerjaan server diorkestrasi oleh dan dijalankan di server (Azure Pipelines atau TFS). Pekerjaan server tidak memerlukan agen atau komputer target apa pun. Hanya beberapa tugas yang didukung dalam pekerjaan server sekarang. Waktu maksimum untuk pekerjaan server adalah 30 hari.

Tugas yang didukung pekerjaan tanpa agen

Saat ini, hanya tugas berikut yang didukung di luar kotak untuk pekerjaan tanpa agen:

• Tugas penundaan
• Memanggil tugas Azure Function
• Memanggil tugas REST API
• Tugas Validasi Manual
• Terbitkan ke tugas Azure Bus Layanan
• Mengkueri tugas Pemberitahuan Azure Monitor
• Tugas Item Kerja Kueri

Karena tugas dapat diperluas, Anda dapat menambahkan lebih banyak tugas tanpa agen dengan menggunakan ekstensi. Batas waktu default untuk pekerjaan tanpa agen adalah 60 menit.

YAML

Sintaks lengkap untuk menentukan pekerjaan server adalah:

jobs:
- job: string
  timeoutInMinutes: number
  cancelTimeoutInMinutes: number
  strategy:
    maxParallel: number
    matrix: { string: { string: string } }

  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

Anda juga dapat menggunakan sintaks yang disederhanakan:

jobs:
- job: string
  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

Klasik

Anda menambahkan pekerjaan server di editor dengan memilih '...' pada saluran Alur di tab Tugas dari alur. Properti untuk pekerjaan server ditampilkan saat Anda memilih pekerjaan di editor.

Dependensi

Saat Anda menentukan beberapa pekerjaan dalam satu tahap, Anda dapat menentukan dependensi di antaranya. Alur harus berisi setidaknya satu pekerjaan tanpa dependensi. Secara default, pekerjaan alur YAML Azure DevOps berjalan secara paralel kecuali dependsOn nilainya diatur.

Catatan

Setiap agen hanya dapat menjalankan satu pekerjaan pada satu waktu. Untuk menjalankan beberapa pekerjaan secara paralel, Anda harus mengonfigurasi beberapa agen. Anda juga memerlukan pekerjaan paralel yang memadai.

YAML

Sintaks untuk menentukan beberapa pekerjaan dan dependensinya adalah:

jobs:
- job: string
  dependsOn: string
  condition: string

Contoh pekerjaan yang dibangun secara berurutan:

jobs:
- job: Debug
  steps:
  - script: echo hello from the Debug build
- job: Release
  dependsOn: Debug
  steps:
  - script: echo hello from the Release build

Contoh pekerjaan yang dibangun secara paralel (tanpa dependensi):

jobs:
- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - script: echo hello from Windows
- job: macOS
  pool:
    vmImage: 'macOS-latest'
  steps:
  - script: echo hello from macOS
- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: echo hello from Linux

Contoh fan out:

jobs:
- job: InitialJob
  steps:
  - script: echo hello from initial job
- job: SubsequentA
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent A
- job: SubsequentB
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent B

Contoh fan-in:

jobs:
- job: InitialA
  steps:
  - script: echo hello from initial A
- job: InitialB
  steps:
  - script: echo hello from initial B
- job: Subsequent
  dependsOn:
  - InitialA
  - InitialB
  steps:
  - script: echo hello from subsequent

Klasik

Untuk menambahkan pekerjaan baru, pilih '...' pada saluran alur di tab Tugas dari alur. Kondisi dan urutan eksekusi untuk pekerjaan ditampilkan saat Anda memilih pekerjaan di editor.

Saat Anda menentukan beberapa pekerjaan dalam alur build, pekerjaan tersebut berjalan secara paralel secara default. Anda dapat menentukan urutan pekerjaan yang harus dijalankan dengan mengonfigurasi dependensi antar pekerjaan. Dependensi pekerjaan tidak didukung dalam alur rilis. Beberapa pekerjaan dalam alur rilis berjalan secara berurutan.

Misalnya, alur yang ditunjukkan di bawah ini membagi eksekusi rilis keseluruhan menjadi pekerjaan eksekusi terpisah dengan menggunakan dua pekerjaan agen dan pekerjaan server.

Dalam contoh di atas:

1. Tugas dalam pekerjaan pertama rilis berjalan pada agen dan, setelah pekerjaan ini selesai, agen dirilis.

2. Pekerjaan server berisi tugas Intervensi Manual yang berjalan pada Azure Pipelines atau TFS. Pekerjaan tidak dijalankan pada, atau memerlukan, agen atau server target apa pun. Tugas Intervensi Manual menampilkan pesannya dan menunggu respons "lanjutkan" atau "tolak" dari pengguna. Dalam contoh ini, jika batas waktu yang dikonfigurasi tercapai, tugas akan secara otomatis menolak penyebaran (atur batas waktu di bagian opsi kontrol ke nol jika Anda tidak ingin respons otomatis dihasilkan).

3. Jika rilis dilanjutkan, tugas dalam pekerjaan ketiga berjalan - mungkin pada agen yang berbeda. Jika rilis ditolak, pekerjaan ini tidak berjalan dan rilis ditandai sebagai gagal.

Penting untuk memahami beberapa konsekuensi dari eksekusi bertahas:

• Setiap pekerjaan mungkin menggunakan agen yang berbeda. Jangan berasumsi bahwa status dari pekerjaan sebelumnya tersedia selama pekerjaan berikutnya.

• Opsi Lanjutkan pada Kesalahan dan Selalu jalankan untuk tugas di setiap pekerjaan tidak berpengaruh pada tugas dalam pekerjaan berikutnya. Misalnya, pengaturan Selalu jalankan pada tugas di akhir pekerjaan pertama tidak akan menjamin bahwa tugas dalam pekerjaan berikutnya berjalan.

Kondisi

Anda dapat menentukan kondisi di mana setiap pekerjaan berjalan. Secara default, pekerjaan berjalan jika tidak bergantung pada pekerjaan lain, atau jika semua pekerjaan yang bergantung pada pekerjaan telah selesai dan berhasil. Anda dapat menyesuaikan perilaku ini dengan memaksa pekerjaan berjalan meskipun pekerjaan sebelumnya gagal atau dengan menentukan kondisi kustom.

YAML

Contoh untuk menjalankan pekerjaan berdasarkan status menjalankan pekerjaan sebelumnya:

jobs:
- job: A
  steps:
  - script: exit 1

- job: B
  dependsOn: A
  condition: failed()
  steps:
  - script: echo this will run when A fails

- job: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')
  steps:
  - script: echo this will run when B runs and succeeds

Contoh penggunaan kondisi kustom:

jobs:
- job: A
  steps:
  - script: echo hello

- job: B
  dependsOn: A
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))
  steps:
  - script: echo this only runs for master

Anda dapat menentukan bahwa pekerjaan berjalan berdasarkan nilai variabel output yang ditetapkan dalam pekerjaan sebelumnya. Dalam hal ini, Anda hanya dapat menggunakan variabel yang diatur dalam pekerjaan dependen langsung:

jobs:
- job: A
  steps:
  - script: "echo '##vso[task.setvariable variable=skipsubsequent;isOutput=true]false'"
    name: printvar

- job: B
  condition: and(succeeded(), ne(dependencies.A.outputs['printvar.skipsubsequent'], 'true'))
  dependsOn: A
  steps:
  - script: echo hello from B

Klasik

Gunakan opsi Jalankan pekerjaan ini pada agen atau pekerjaan server untuk menjalankan tugas hanya ketika kondisi tertentu terpenuhi. Pilih kondisi yang telah ditentukan sebelumnya, atau pilih "kustom" dan masukkan ekspresi yang mengevaluasi ke true atau false. Ekspresi berlapis dapat digunakan, dan ekspresi dapat mengakses variabel yang tersedia dalam alur rilis.

Waktu habis

Untuk menghindari mengambil sumber daya ketika pekerjaan Anda tidak responsif atau menunggu terlalu lama, ada baiknya menetapkan batasan berapa lama pekerjaan Anda diizinkan untuk dijalankan. Gunakan pengaturan batas waktu pekerjaan untuk menentukan batas dalam menit untuk menjalankan pekerjaan. Mengatur nilai ke nol berarti pekerjaan dapat berjalan:

• Selamanya pada agen yang dihost sendiri
• Selama 360 menit (6 jam) pada agen yang dihosting Microsoft dengan proyek publik dan repositori publik
• Selama 60 menit pada agen yang dihosting Microsoft dengan proyek privat atau repositori privat (kecuali kapasitas tambahan dibayarkan)

Periode batas waktu dimulai ketika pekerjaan mulai berjalan. Ini tidak termasuk waktu pekerjaan diantrekan atau sedang menunggu agen.

YAML

memungkinkan timeoutInMinutes batas untuk diatur untuk waktu eksekusi pekerjaan. Ketika tidak ditentukan, defaultnya adalah 60 menit. Ketika 0 ditentukan, batas maksimum digunakan (dijelaskan di atas).

cancelTimeoutInMinutes memungkinkan batas untuk diatur untuk waktu pembatalan pekerjaan ketika tugas penyebaran diatur untuk terus berjalan jika tugas sebelumnya gagal. Ketika tidak ditentukan, defaultnya adalah 5 menit. Nilai harus berkisar antara 1 hingga 35790 menit.

jobs:
- job: Test
  timeoutInMinutes: 10 # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: 2 # how much time to give 'run always even if cancelled tasks' before stopping them

Klasik

Pilih pekerjaan lalu tentukan nilai batas waktu.

Pada tab Opsi, Anda dapat menentukan nilai default untuk semua pekerjaan dalam alur. Jika Anda menentukan nilai bukan nol untuk batas waktu pekerjaan, nilai tersebut akan mengambil alih nilai apa pun yang ditentukan dalam opsi alur. Jika Anda menentukan nilai nol, maka nilai batas waktu dari opsi alur digunakan. Jika nilai alur juga diatur ke nol, maka tidak ada batas waktu.

Batas waktu memiliki tingkat prioritas berikut.

1. Pada agen yang dihosting Microsoft, pekerjaan dibatasi dalam berapa lama mereka dapat berjalan berdasarkan jenis proyek dan apakah mereka dijalankan menggunakan pekerjaan paralel berbayar. Ketika interval batas waktu pekerjaan yang dihosting Microsoft berlalu, pekerjaan dihentikan. Pada agen yang dihosting Microsoft, pekerjaan tidak dapat berjalan lebih lama dari interval ini, terlepas dari batas waktu tingkat pekerjaan apa pun yang ditentukan dalam pekerjaan.
2. Batas waktu yang dikonfigurasi pada tingkat pekerjaan menentukan durasi maksimum untuk pekerjaan yang akan dijalankan. Ketika interval batas waktu tingkat pekerjaan berlalu, pekerjaan dihentikan. Jika pekerjaan dijalankan pada agen yang dihosting Microsoft, mengatur batas waktu tingkat pekerjaan ke interval yang lebih besar dari batas waktu tingkat pekerjaan bawaan yang dihosting Microsoft tidak berpengaruh dan batas waktu pekerjaan yang dihosting Microsoft digunakan.
3. Anda juga dapat mengatur batas waktu untuk setiap tugas satu per satu - lihat opsi kontrol tugas. Jika interval batas waktu tingkat pekerjaan berlalu sebelum tugas selesai, pekerjaan yang sedang berjalan dihentikan, bahkan jika tugas dikonfigurasi dengan interval batas waktu yang lebih lama.

Konfigurasi multi-pekerjaan

Dari satu pekerjaan yang Anda tulis, Anda dapat menjalankan beberapa pekerjaan di beberapa agen secara paralel. Beberapa contohnya termasuk:

• Build multi-konfigurasi: Anda dapat membangun beberapa konfigurasi secara paralel. Misalnya, Anda dapat membangun aplikasi Visual C++ untuk konfigurasi dan debug release di platform dan .x86 x64 Untuk informasi selengkapnya, lihat Visual Studio Build - beberapa konfigurasi untuk beberapa platform.

• Penyebaran multi-konfigurasi: Anda dapat menjalankan beberapa penyebaran secara paralel, misalnya, ke wilayah geografis yang berbeda.

• Pengujian multi-konfigurasi: Anda dapat menjalankan pengujian beberapa konfigurasi secara paralel.

• Multi-konfigurasi akan selalu menghasilkan setidaknya satu pekerjaan, bahkan jika variabel multi-konfigurasi kosong.

YAML

Strategi ini matrix memungkinkan pekerjaan dikirim beberapa kali, dengan set variabel yang berbeda. Tag maxParallel membatasi jumlah paralelisme. Pekerjaan berikut dikirim tiga kali dengan nilai Lokasi dan Browser yang ditetapkan sebagaimana ditentukan. Namun, hanya dua pekerjaan yang berjalan pada saat yang sama.

jobs:
- job: Test
  strategy:
    maxParallel: 2
    matrix: 
      US_IE:
        Location: US
        Browser: IE
      US_Chrome:
        Location: US
        Browser: Chrome
      Europe_Chrome:
        Location: Europe
        Browser: Chrome

Catatan

Nama konfigurasi matriks (seperti US_IE di atas) hanya boleh berisi huruf alfabet Latin dasar (A-Z, a-z), angka, dan garis bawah (_). Nama kolom harus diawali dengan huruf. Selain itu, mereka harus 100 karakter atau kurang.

Anda juga dapat menggunakan variabel output untuk menghasilkan matriks . Ini bisa berguna jika Anda perlu membuat matriks menggunakan skrip.

matrix menerima ekspresi runtime yang berisi objek JSON yang di string. Objek JSON itu, ketika diperluas, harus cocok dengan sintaks matriks. Dalam contoh di bawah ini, kami telah mengkodekan string JSON secara permanen, tetapi dapat dihasilkan oleh bahasa skrip atau program baris perintah.

jobs:
- job: generator
  steps:
  - bash: echo "##vso[task.setVariable variable=legs;isOutput=true]{'a':{'myvar':'A'}, 'b':{'myvar':'B'}}"
    name: mtrx
  # This expands to the matrix
  #   a:
  #     myvar: A
  #   b:
  #     myvar: B
- job: runner
  dependsOn: generator
  strategy:
    matrix: $[ dependencies.generator.outputs['mtrx.legs'] ]
  steps:
  - script: echo $(myvar) # echos A or B depending on which leg is running

Klasik

Untuk menjalankan beberapa pekerjaan menggunakan opsi multi-konfigurasi, Anda mengidentifikasi variabel bernama pengali, dan menentukan daftar nilai untuk pengali tersebut. Pekerjaan terpisah dijalankan untuk setiap nilai dalam daftar. Untuk menggunakan pengali untuk build atau penyebaran, Anda harus:

• Tentukan satu atau beberapa variabel pada tab Variabel dari alur atau dalam grup variabel. Setiap variabel, yang dikenal dalam konteks ini sebagai variabel pengali , harus didefinisikan sebagai daftar nilai yang dibatasi koma yang ingin Anda teruskan satu per satu ke agen.

• Masukkan nama variabel pengali, tanpa $ tanda kurung dan , sebagai nilai parameter Pengali . Menggunakan variabel rahasia sebagai variabel pengali tidak didukung.

• Jika Anda ingin menjalankan pekerjaan untuk lebih dari satu variabel pengali, masukkan nama variabel sebagai daftar yang dibatasi koma - menghilangkan $ tanda kurung dan untuk masing-masing variabel.

• Jika Anda ingin membatasi jumlah agen yang digunakan selama penyebaran ke angka yang kurang dari yang telah Anda konfigurasikan untuk langganan Anda, masukkan nilai tersebut sebagai Parameter Jumlah maksimum agen .

Misalnya, Anda dapat menentukan dua variabel bernama Lokasi dan Browser sebagai berikut:

• Location = US,Europe
• Browser = IE,Chrome,Edge,Firefox

Konfigurasi berikut menjalankan penyebaran delapan kali menggunakan maksimal empat agen kapan saja:

• Pengganda = Location,Browser
• Jumlah maksimum agen = 4

Dengan multi-konfigurasi, Anda dapat menjalankan beberapa pekerjaan, masing-masing dengan nilai yang berbeda untuk satu, atau lebih variabel (perkalian). Jika Anda ingin menjalankan pekerjaan yang sama pada beberapa agen, maka Anda dapat menggunakan opsi paralelisme multi-agen . Contoh pemotongan pengujian di atas dapat dicapai melalui opsi multi-agen.

Membelah

Pekerjaan agen dapat digunakan untuk menjalankan serangkaian pengujian secara paralel. Misalnya, Anda dapat menjalankan rangkaian besar 1000 pengujian pada satu agen. Atau, Anda dapat menggunakan dua agen dan menjalankan 500 pengujian pada masing-masing secara paralel.

Untuk menerapkan pemotongan, tugas dalam pekerjaan harus cukup cerdas untuk memahami irisan miliknya.

Tugas Uji Visual Studio adalah salah satu tugas seperti itu yang mendukung pemotongan pengujian. Jika Anda menginstal beberapa agen, Anda dapat menentukan bagaimana tugas Pengujian Visual Studio berjalan secara paralel pada agen ini.

YAML

Strategi ini parallel memungkinkan pekerjaan diduplikasi berkali-kali. System.JobPositionInPhase Variabel dan System.TotalJobsInPhase ditambahkan ke setiap pekerjaan. Variabel kemudian dapat digunakan dalam skrip Anda untuk membagi pekerjaan di antara pekerjaan. Lihat Paralel dan beberapa eksekusi menggunakan pekerjaan agen.

Pekerjaan berikut dikirim lima kali dengan nilai System.JobPositionInPhase dan System.TotalJobsInPhase diatur dengan tepat.

jobs:
- job: Test
  strategy:
    parallel: 5

Klasik

Tentukan opsi multi-agen pada pekerjaan agen untuk menerapkan pemotongan. Pekerjaan dikirim sebanyak jumlah agen yang Anda tentukan, dan variabel System.JobPositionInPhase dan System.TotalJobsInPhase secara otomatis diatur dalam setiap pekerjaan.

Variabel pekerjaan

Jika Anda menggunakan YAML, variabel dapat ditentukan pada pekerjaan. Variabel dapat diteruskan ke input tugas menggunakan sintaks makro $(variableName), atau diakses dalam skrip menggunakan variabel tahap.

YAML

Berikut adalah contoh menentukan variabel dalam pekerjaan dan menggunakannya dalam tugas.

variables:
  mySimpleVar: simple var value
  "my.dotted.var": dotted var value
  "my var with spaces": var with spaces value

steps:
- script: echo Input macro = $(mySimpleVar). Env var = %MYSIMPLEVAR%
  condition: eq(variables['agent.os'], 'Windows_NT')
- script: echo Input macro = $(mySimpleVar). Env var = $MYSIMPLEVAR
  condition: in(variables['agent.os'], 'Darwin', 'Linux')
- bash: echo Input macro = $(my.dotted.var). Env var = $MY_DOTTED_VAR
- powershell: Write-Host "Input macro = $(my var with spaces). Env var = $env:MY_VAR_WITH_SPACES"

Klasik

Variabel pekerjaan belum didukung di editor web.

Untuk informasi tentang menggunakan kondisi, lihat Menentukan kondisi.

Ruang kerja

Saat Anda menjalankan pekerjaan kumpulan agen, ia membuat ruang kerja pada agen. Ruang kerja adalah direktori di mana ia mengunduh sumber, menjalankan langkah-langkah, dan menghasilkan output. Direktori ruang kerja dapat direferensikan dalam pekerjaan Anda menggunakan Pipeline.Workspace variabel. Di bawah ini, berbagai subdirektori dibuat:

• Build.SourcesDirectory adalah tempat tugas mengunduh kode sumber aplikasi.
• Build.ArtifactStagingDirectory adalah tempat tugas mengunduh artefak yang diperlukan untuk alur atau mengunggah artefak sebelum diterbitkan.
• Build.BinariesDirectory adalah tempat tugas menulis output mereka.
• Common.TestResultsDirectory adalah tempat tugas mengunggah hasil pengujian mereka.

YAML

$(Build.ArtifactStagingDirectory) dan $(Common.TestResultsDirectory) selalu dihapus dan dibuat ulang sebelum setiap build.

Saat Anda menjalankan alur pada agen yang dihost sendiri, secara default, tidak ada subdirektori selain $(Build.ArtifactStagingDirectory) dan $(Common.TestResultsDirectory) dibersihkan di antara dua eksekusi berturut-turut. Akibatnya, Anda dapat melakukan build dan penyebaran bertahap, asalkan tugas diimplementasikan untuk memanfaatkannya. Anda dapat mengambil alih perilaku ini menggunakan workspace pengaturan pada pekerjaan.

Penting

Opsi bersih ruang kerja hanya berlaku untuk agen yang dihost sendiri. Pekerjaan selalu dijalankan pada agen baru dengan agen yang dihosting Microsoft.

- job: myJob
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Saat Anda menentukan salah satu opsi, opsi tersebut clean ditafsirkan sebagai berikut:

• outputs: Hapus Build.BinariesDirectory sebelum menjalankan pekerjaan baru.
• resources: Hapus Build.SourcesDirectory sebelum menjalankan pekerjaan baru.
• all: Hapus seluruh Pipeline.Workspace direktori sebelum menjalankan pekerjaan baru.

  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Catatan

Tergantung pada kemampuan agen dan permintaan alur Anda, setiap pekerjaan dapat dirutekan ke agen yang berbeda di kumpulan yang dihost sendiri. Akibatnya, Anda mungkin mendapatkan agen baru untuk eksekusi alur berikutnya (atau tahap atau pekerjaan dalam alur yang sama), jadi tidak membersihkan bukanlah jaminan bahwa eksekusi, pekerjaan, atau tahap berikutnya akan dapat mengakses output dari eksekusi, pekerjaan, atau tahap sebelumnya. Anda dapat mengonfigurasi kemampuan agen dan tuntutan alur untuk menentukan agen mana yang digunakan untuk menjalankan pekerjaan alur, tetapi kecuali hanya ada satu agen di kumpulan yang memenuhi tuntutan, tidak ada jaminan bahwa pekerjaan berikutnya akan menggunakan agen yang sama dengan pekerjaan sebelumnya. Untuk informasi selengkapnya, lihat Menentukan permintaan.

Selain membersihkan ruang kerja, Anda juga dapat mengonfigurasi pembersihan dengan mengonfigurasi pengaturan Bersihkan di antarmuka pengguna pengaturan alur. Saat pengaturan Bersihkan benar, yang juga merupakan nilai defaultnya, setara dengan menentukan clean: true untuk setiap langkah checkout di alur Anda. Saat Anda menentukan clean: true, Anda akan berjalan git clean -ffdx diikuti oleh git reset --hard HEAD sebelum pengambilan git. Untuk mengonfigurasi pengaturan Bersih :

1. Edit alur Anda, pilih ..., dan pilih Pemicu.

   

2. Pilih YAML, Dapatkan sumber, dan konfigurasikan pengaturan Bersih yang Anda inginkan. Defaultnya adalah true

   

Klasik

Saat Anda menjalankan alur pada agen yang dihost sendiri, secara default, tidak ada subdirektori yang dibersihkan di antara dua eksekusi berturut-turut. Akibatnya, Anda dapat menjalankan build dan penyebaran inkremental, asalkan tugas diimplementasikan untuk melakukannya. Namun, Anda dapat mengambil alih perilaku ini menggunakan opsi di Clean build bawah Get sources tugas. Opsi bervariasi tergantung pada jenis repositori yang Anda gunakan.

• GitHub
• Azure Repos Git
• TFVC

Unduhan artefak

Contoh file YAML ini menerbitkan artefak WebSite lalu mengunduh artefak ke $(Pipeline.Workspace). Pekerjaan Sebarkan hanya berjalan jika pekerjaan Build berhasil.

YAML

# test and upload my code as an artifact named WebSite
jobs:
- job: Build
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: npm test
  - task: PublishBuildArtifacts@1
    inputs:
      pathtoPublish: '$(System.DefaultWorkingDirectory)'
      artifactName: WebSite

# download the artifact and deploy it only if the build job succeeded
- job: Deploy
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - checkout: none #skip checking out the default repository resource
  - task: DownloadBuildArtifacts@0
    displayName: 'Download Build Artifacts'
    inputs:
      artifactName: WebSite
      downloadPath: $(Pipeline.Workspace)

  dependsOn: Build
  condition: succeeded()

Klasik

Dalam alur rilis, Anda dapat memilih untuk melewati pengunduhan artefak selama eksekusi pekerjaan. Gunakan opsi ini jika Anda ingin menerapkan logika kustom Anda sendiri untuk mengunduh artefak dengan menggunakan tugas, atau jika tugas dalam pekerjaan tertentu tidak bergantung pada artefak.

Atau, Anda dapat memilih untuk mengunduh artefak tertentu selama eksekusi pekerjaan dalam rilis. Gunakan opsi ini jika tugas dalam pekerjaan tertentu hanya mengandalkan artefak tertentu.

Untuk informasi tentang menggunakan dependsOn dan kondisi, lihat Menentukan kondisi.

Akses ke token OAuth

Anda dapat mengizinkan skrip yang berjalan dalam pekerjaan untuk mengakses token keamanan Azure Pipelines atau TFS OAuth saat ini. Token dapat digunakan untuk mengautentikasi ke AZURE Pipelines REST API.

YAML

Token OAuth selalu tersedia untuk alur YAML. Ini harus secara eksplisit dipetakan ke dalam tugas atau langkah menggunakan env. Berikut contohnya:

steps:
- powershell: |
    $url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/definitions/$($env:SYSTEM_DEFINITIONID)?api-version=4.1-preview"
    Write-Host "URL: $url"
    $pipeline = Invoke-RestMethod -Uri $url -Headers @{
      Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
    }
    Write-Host "Pipeline = $($pipeline | ConvertTo-Json -Depth 100)"
  env:
    SYSTEM_ACCESSTOKEN: $(system.accesstoken)

Klasik

Pilih opsi Izinkan skrip untuk mengakses token OAuth di opsi kontrol untuk pekerjaan tersebut. Token tersedia sebagai variabel SYSTEM_ACCESSTOKENlingkungan .

Selanjutnya

• Pekerjaan grup penyebaran
• Kondisi