Spesifikasikan pekerjaan dalam pipeline Anda

Layanan Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Anda dapat mengatur alur kerja Anda menjadi pekerjaan-pekerjaan. Setiap jalur memiliki setidaknya satu tugas. 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, jalur pemrosesan memiliki satu tugas. 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 yang dihosting oleh Microsoft dan menghasilkan output.

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

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

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

Pipeline Anda bisa memiliki beberapa tugas. Dalam hal ini, gunakan jobs kata kunci.

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

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

Alur Anda dapat 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 tugas 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 pekerjaan penyebaran dalam job, kami sarankan Anda menggunakan pekerjaan penyebaran. Tugas penerapan memiliki beberapa manfaat. Misalnya, Anda dapat menyebarkan ke lingkungan, yang termasuk manfaat seperti dapat melihat riwayat dari apa yang telah Anda sebarkan.

Klasik

Untuk menambahkan job ke pipeline build Anda, edit pipeline di halaman Pipelines. Pilih ... untuk menambahkan pekerjaan.

Untuk menambahkan tugas ke jalur proses rilis Anda, edit jalur proses dari Pipelines>Releases. Lihat tugas di tahap di mana Anda ingin menambahkan pekerjaan Anda. Pilih ... untuk menambahkan pekerjaan.

Jenis pekerjaan

Pekerjaan dapat berupa berbagai jenis, tergantung di mana mereka dijalankan.

YAML

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

Klasik

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

Pekerjaan kumpulan agen

Pekerjaan kumpulan agen adalah pekerjaan yang paling umum. Pekerjaan ini dijalankan oleh agen dalam pool agen. Anda dapat menentukan kumpulan untuk menjalankan pekerjaan, dan Anda juga dapat menentukan tuntutan untuk menentukan kemampuan apa yang harus dimiliki agen untuk menjalankan pekerjaan Anda. Agen dapat dihosting microsoft atau dihost sendiri. Untuk informasi selengkapnya, lihat agen Azure Pipelines .

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

Catatan

Tuntutan dan kemampuan dirancang untuk digunakan dengan agen yang dihost sendiri sehingga pekerjaan dapat dipasangkan dengan agen yang dapat memenuhi persyaratan pekerjaan. Saat menggunakan agen yang dihosting Microsoft, Anda memilih gambar untuk agen yang cocok dengan persyaratan pekerjaan. 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 dapat menentukan kebutuhan dalam alur, dalam tugas, atau keduanya. Jika Anda menentukan persyaratan dalam alur kerja dan dalam pekerjaan, gabungan kedua set persyaratan diperlukan agar sistem dapat memilih agen.

Pelajari selengkapnya tentang kemampuan agen.

Pekerjaan server

Server mengatur dan menjalankan tugas dalam pekerjaan server. 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 oleh pekerjaan tanpa agen

Saat ini, hanya tugas berikut yang didukung secara bawaan untuk tugas tanpa agen:

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

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 Pipeline di tab Tugas dari suatu pipeline. 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. Rangkaian harus memiliki setidaknya satu tugas tanpa ketergantungan. Secara default, tugas alur YAML Azure DevOps berjalan secara paralel kecuali nilai dependsOn ditetapkan.

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 penyebaran:

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 penerapan 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 di tab Tugas dalam jalur pipa. 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 membagi eksekusi rilis keseluruhan menjadi pekerjaan eksekusi terpisah dengan menggunakan dua pekerjaan agen dan pekerjaan server .

1. Tugas dalam pekerjaan pertama rilis dijalankan pada agen. Agen dirilis setelah tugas selesai.

2. Pekerjaan server berisi tugas Intervensi Manual yang berjalan di Azure Pipelines atau DevOps Server. 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 tugas mencapai batas waktu yang dikonfigurasi, tugas secara otomatis menolak penyebaran. Atur batas waktu di bagian opsi kontrol ke nol jika Anda tidak ingin respons otomatis dibuat.

3. Tugas dalam pekerjaan ketiga tersebut akan dijalankan jika peluncuran dilanjutkan, mungkin pada agen yang berbeda. Jika rilis ditolak, pekerjaan ini tidak berjalan dan rilis ditandai sebagai gagal.

Penting untuk memahami beberapa konsekuensi dari pelaksanaan bertahap.

• Setiap pekerjaan mungkin menggunakan agen yang berbeda. Jangan berasumsi bahwa keadaan dari pekerjaan sebelumnya akan ada pada 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 proyek pertama tidak menjamin bahwa tugas dalam proyek berikutnya dijalankan.

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 berhasil diselesaikan. Anda dapat menyesuaikan perilaku ini dengan memaksa pekerjaan berjalan meskipun pekerjaan sebelumnya gagal atau dengan menentukan kondisi kustom.

YAML

Contoh untuk menjalankan tugas berdasarkan status pelaksanaan tugas 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 dari 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 ditetapkan dalam pekerjaan yang langsung bergantung:

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.

Batas Waktu

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

• Selamanya di agen yang disediakan sendiri
• Selama 360 menit (6 jam) pada agen yang dihosting Microsoft dengan proyek publik dan repositori terbuka
• Selama 60 menit pada agen yang di-host oleh Microsoft dengan proyek privat atau repositori privat (kecuali kapasitas tambahan telah dibayar)

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

YAML

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

Fungsi cancelTimeoutInMinutes memungkinkan untuk menentukan batas 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.

Jeda waktu memiliki level prioritas berikut.

1. Pada agen yang dihosting Microsoft, tugas dibatasi durasinya berdasarkan jenis proyek dan apakah dijalankan menggunakan pekerjaan paralel berbayar. Ketika batas waktu pekerjaan yang dioperasikan oleh Microsoft berlalu, pekerjaan dihentikan. Pada agen yang dihosting oleh Microsoft, pekerjaan tidak dapat berjalan lebih lama dari jangka waktu ini, terlepas dari batas waktu pekerjaan yang telah ditentukan.
2. Batas waktu yang dikonfigurasi pada tingkat pekerjaan menentukan durasi maksimum untuk pekerjaan yang akan dijalankan. Ketika interval batas waktu pada tingkat pekerjaan berakhir, pekerjaan tersebut dihentikan. Saat tugas dijalankan pada agen yang dihosting oleh Microsoft, menetapkan waktu habis tingkat pekerjaan yang lebih besar dari waktu habis tingkat pekerjaan bawaan dari Microsoft tidak akan berpengaruh.
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 pekerjaan ganda

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

• Pembangunan multi-konfigurasi: Anda dapat membuat beberapa konfigurasi secara paralel. Misalnya, Anda dapat membangun aplikasi Visual C++ untuk konfigurasi debug dan release pada platform x86 dan 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 selalu menghasilkan setidaknya satu tugas, bahkan jika variabel multi-konfigurasi tersebut kosong.

YAML

Strategi matrix ini memungkinkan pekerjaan dieksekusi beberapa kali, dengan set variabel yang berbeda. Tag maxParallel membatasi jumlah paralelisme. Pekerjaan berikut dijalankan tiga kali dengan nilai Lokasi dan Browser yang ditetapkan. 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 dalam contoh) hanya boleh berisi huruf alfabet Latin dasar (A - Z, a - z), angka, dan garis bawah (_). Mereka harus dimulai dengan huruf. Selain itu, mereka harus 100 karakter atau kurang.

Anda juga dapat menggunakan variabel output untuk menghasilkan matriks . Metode ini dapat berguna jika Anda perlu menghasilkan matriks menggunakan skrip.

matrix menerima ekspresi runtime yang berisi objek JSON dalam bentuk string. Objek JSON itu, ketika diperluas, harus cocok dengan sintaks matriks. Dalam contoh berikut, kami mengkodekan string JSON secara permanen, tetapi Anda dapat membuatnya dengan 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 pengganda saat membangun atau melakukan 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 tugas untuk lebih dari satu variabel pengali, masukkan nama variabel sebagai daftar yang dipisahkan dengan koma, tanpa mencantumkan $ dan tanda kurung untuk setiap variabel.

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

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

• Tempat = US,Europe
• Peramban = IE,Chrome,Edge,Firefox

Konfigurasi berikut menjalankan deploy sebanyak delapan kali dengan menggunakan maksimal empat agen pada waktu bersamaan:

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

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

Membelah

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

Untuk menerapkan pemotongan, tugas-tugas dalam suatu pekerjaan harus cukup cerdas untuk memahami irisan yang mereka miliki.

Tugas Visual Studio Test adalah tugas yang mendukung pembagian 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. Variabel System.JobPositionInPhase dan System.TotalJobsInPhase ditambahkan ke setiap pekerjaan. Variabel kemudian dapat digunakan dalam skrip Anda untuk membagi pekerjaan di antara pekerjaan. Lihat Eksekusi paralel dan multi menggunakan tugas agen.

Tugas berikut dijalankan lima kali dengan nilai System.JobPositionInPhase dan System.TotalJobsInPhase disetel dengan benar.

jobs:
- job: Test
  strategy:
    parallel: 5

Klasik

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

Variabel pekerjaan

Jika Anda menggunakan YAML, variabel dapat diatur pada tugas. 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, itu 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 di mana tugas mengunduh artefak yang diperlukan untuk rangkaian proses atau mengunggah artefak sebelum diterbitkan.
• Build.BinariesDirectory adalah tempat hasil tugas dicatatkan.
• 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) yang dibersihkan di antara dua pelaksanaan berturut-turut. Akibatnya, Anda dapat melakukan build dan penyebaran bertahap, jika tugas diimplementasikan untuk memanfaatkan fitur tersebut. Anda dapat mengambil alih perilaku ini menggunakan pengaturan workspace di dalam pekerjaan.

Penting

Opsi bersih ruang kerja hanya berlaku untuk agen yang dihost sendiri. Pekerjaan selalu dijalankan pada agen baru yang dihosting oleh 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 kebutuhan alur kerja Anda, setiap pekerjaan dapat dirutekan ke agen yang berbeda di kumpulan yang dihosting sendiri. Akibatnya, Anda bisa mendapatkan agen baru untuk eksekusi alur berikutnya (atau tahapan atau pekerjaan dalam alur yang sama), sehingga dan bukan, pembersihan tidak menjamin bahwa eksekusi, pekerjaan, atau tahap berikutnya dapat mengakses keluaran dari eksekusi, pekerjaan, atau tahap sebelumnya. Anda dapat mengonfigurasi kemampuan agen dan permintaan 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 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 diatur menjadi true, yang juga merupakan nilai defaultnya, ini setara dengan menentukan clean: true untuk setiap langkah checkout di alur kerja Anda. Saat Anda menentukan clean: true, Anda menjalankan git clean -ffdx diikuti dengan git reset --hard HEAD sebelum mengambil dari 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 pipeline pada agen yang dihost sendiri, secara default, tidak ada subdirektori yang dibersihkan di antara dua kali eksekusi berturut-turut. Akibatnya, Anda dapat menjalankan pembangunan dan penerapan bertahap, jika tugas diimplementasikan untuk melakukannya. Namun, Anda dapat mengganti perilaku ini menggunakan opsi Clean build untuk tugas Get sources. 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). Tugas Deploy hanya berjalan jika tugas 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: PublishPipelineArtifact@1
    inputs:
      artifactName: Website
      targetPath: '$(System.DefaultWorkingDirectory)'

# 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: DownloadPipelineArtifact@2
    displayName: 'Download Pipeline Artifact'
    inputs:
      artifactName: Website
      targetPath: '$(Pipeline.Workspace)'
  dependsOn: Build
  condition: succeeded()

Klasik

Dalam alur rilis, Anda dapat memilih untuk melewati unduhan artefak-artefak selama pelaksanaan tugas. 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 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 lingkungan SYSTEM_ACCESSTOKEN.

Apa berikutnya

• Pekerjaan dalam grup penyebaran
• Kondisi