Menambahkan tahapan, dependensi, & kondisi

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

Tahap adalah batas logis dalam alur Azure DevOps. Tahapan dapat digunakan untuk mengelompokkan tindakan dalam proses pengembangan perangkat lunak Anda (misalnya, membangun aplikasi, menjalankan pengujian, menyebarkan ke praproduksi). Setiap tahap berisi satu atau beberapa pekerjaan.

Saat Anda menentukan beberapa tahap dalam alur, secara default, mereka menjalankan satu demi satu. Tahapan juga dapat bergantung satu sama lain. Anda dapat menggunakan dependsOn kata kunci untuk menentukan dependensi. Tahapan juga dapat berjalan berdasarkan hasil tahap sebelumnya dengan kondisi.

Untuk mempelajari cara kerja tahapan dengan pekerjaan dan lisensi paralel, lihat Mengonfigurasi dan membayar pekerjaan paralel.

Untuk mengetahui bagaimana tahapan terkait dengan bagian lain dari alur seperti pekerjaan, lihat Konsep alur utama.

Anda juga dapat mempelajari selengkapnya tentang bagaimana tahapan terkait dengan bagian alur dalam artikel tahapan skema YAML.

YAML

Anda dapat mengatur pekerjaan alur menjadi beberapa tahapan. Tahapan adalah divisi utama dalam alur: membangun aplikasi ini, menjalankan pengujian ini, dan menyebarkan ke praproduksi adalah contoh tahap yang baik. Ini adalah batas logis di alur Anda di mana Anda dapat menjeda alur dan melakukan berbagai pemeriksaan.

Setiap alur memiliki setidaknya satu tahap bahkan jika Anda tidak secara eksplisit mendefinisikannya. Anda juga dapat mengatur tahapan ke dalam grafik dependensi sehingga satu tahap berjalan di depan tahap lain. Ada batas 256 pekerjaan untuk satu tahap.

Klasik

Atur pekerjaan penyebaran dalam alur rilis Anda ke dalam tahapan. Tahapan adalah divisi utama dalam alur rilis Anda: menjalankan pengujian fungsional, menyebarkan ke praproduksi, dan menyebarkan ke produksi adalah contoh tahap rilis yang baik.

Tahap dalam alur rilis terdiri dari pekerjaan dan tugas.

Persetujuan dan gerbang, kondisi dan pemicu penyebaran, dan kontrol kebijakan antrean saat rilis disebarkan ke tahap.

Tentukan tahapan

YAML

Dalam kasus paling sederhana, Anda tidak memerlukan batas logis apa pun di alur Anda. Dalam hal ini, Anda tidak perlu secara eksplisit menggunakan stage kata kunci. Anda dapat langsung menentukan pekerjaan dalam file YAML Anda.

# this has one implicit stage and one implicit job
pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

# this pipeline has one implicit stage
jobs:
- job: A
  steps:
  - bash: echo "A"

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

Jika Anda mengatur alur Anda ke dalam beberapa tahap, Anda menggunakan stages kata kunci.

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

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

Jika Anda memilih untuk menentukan pool pada tingkat tahap, maka semua pekerjaan yang ditentukan dalam tahap tersebut menggunakan kumpulan tersebut kecuali ditentukan pada tingkat pekerjaan.

stages:
- stage: A
  pool: StageAPool
  jobs:
  - job: A1 # will run on "StageAPool" pool based on the pool defined on the stage
  - job: A2 # will run on "JobPool" pool
    pool: JobPool

Sintaks lengkap untuk menentukan tahap adalah:

stages:
- stage: string  # name of the stage, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  pool: string | pool
  variables: { string: string } | [ variable | variableReference ] 
  jobs: [ job | templateReference]

Klasik

Untuk menambahkan tahap ke alur rilis Anda, pilih alur rilis di halaman Rilis , pilih tindakan untuk Mengeditnya , lalu pilih tab Alur . Meskipun bagian terpenting dari menentukan tahap adalah tugas otomatisasi, Anda juga dapat mengonfigurasi beberapa properti dan opsi untuk tahap dalam alur rilis. Anda dapat:

• Edit nama tahap di sini jika perlu.
• Menunjuk satu pengguna atau grup untuk menjadi pemilik panggung. Pemilik tahap mendapatkan pemberitahuan setiap kali penyebaran ke tahap tersebut gagal. Menjadi pemilik panggung tidak secara otomatis dilengkapi dengan izin apa pun.
• Hapus tahap dari alur.
• Ubah urutan tahapan.
• Simpan salinan tahap sebagai templat tahapan.
• Kelola pengaturan keamanan untuk tahap tersebut.

Tentukan dependensi

YAML

Saat Anda menentukan beberapa tahap dalam alur, secara default, mereka berjalan secara berurutan dalam urutan di mana Anda menentukannya dalam file YAML. Pengecualian untuk ini adalah ketika Anda menambahkan dependensi. Dengan dependensi, tahapan berjalan sesuai urutan dependsOn persyaratan.

Alur harus berisi setidaknya satu tahap tanpa dependensi.

Sintaks untuk menentukan beberapa tahap dan dependensinya adalah:

stages:
- stage: string
  dependsOn: string
  condition: string

Contoh tahapan yang berjalan secara berurutan:

# if you do not use a dependsOn keyword, stages run in the order they are defined
stages:
- stage: QA
  jobs:
  - job:
    ...

- stage: Prod
  jobs:
  - job:
    ...

Contoh tahapan yang berjalan secara paralel:

stages:
- stage: FunctionalTest
  jobs:
  - job:
    ...

- stage: AcceptanceTest
  dependsOn: []    # this removes the implicit dependency on previous stage and causes this to run in parallel
  jobs:
  - job:
    ...

Contoh fan-out dan fan-in:

stages:
- stage: Test

- stage: DeployUS1
  dependsOn: Test    # this stage runs after Test

- stage: DeployUS2
  dependsOn: Test    # this stage runs in parallel with DeployUS1, after Test

- stage: DeployEurope
  dependsOn:         # this stage runs after DeployUS1 and DeployUS2
  - DeployUS1
  - DeployUS2

Klasik

Anda mengontrol dependensi dengan mengatur pemicu pada setiap tahap alur rilis:

• Tahapan berjalan dengan pemicu atau dengan memulai secara manual.
• Dengan pemicu Setelah rilis, tahap dimulai segera setelah rilis dimulai, secara paralel dengan tahap lain yang memiliki pemicu Setelah rilis.
• Dengan pemicu tahap Setelah, tahap akan dimulai setelah semua tahap dependen selesai. Dengan menggunakan ini, Anda dapat memodelkan perilaku fan-out dan fan-in untuk tahapan.

Tentukan kondisi

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

Jika Anda menyesuaikan kondisi default langkah-langkah sebelumnya untuk suatu tahap, Anda menghapus kondisi untuk penyelesaian dan keberhasilan. Jadi, jika Anda menggunakan kondisi kustom, biasanya digunakan and(succeeded(),custom_condition) untuk memeriksa apakah tahap sebelumnya berhasil dijalankan. Jika tidak, tahap berjalan terlepas dari hasil tahap sebelumnya.

Catatan

Kondisi untuk gagal ('JOBNAME/STAGENAME') dan berhasil ('JOBNAME/STAGENAME') seperti yang ditunjukkan dalam contoh berikut hanya berfungsi untuk alur YAML.

YAML

Contoh untuk menjalankan tahap berdasarkan status menjalankan tahap sebelumnya:

stages:
- stage: A

# stage B runs if A fails
- stage: B
  condition: failed()

# stage C runs if B succeeds
- stage: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')

Contoh penggunaan kondisi kustom:

stages:
- stage: A

- stage: B
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))

Klasik

Saat Anda menentukan Setelah rilis atau Setelah pemicu tahap , Anda juga dapat menentukan filter cabang untuk artefak yang digunakan dalam rilis. Rilis hanya akan disebarkan ke tahap ketika filter cabang terpenuhi.

Tentukan kebijakan antrean

YAML

Alur YAML tidak mendukung kebijakan antrean. Setiap eksekusi alur independen dari dan tidak menyadari eksekusi lain. Dengan kata lain, dua penerapan berturut-turut Anda dapat memicu dua alur, dan keduanya akan menjalankan urutan tahap yang sama tanpa menunggu satu sama lain. Meskipun kami bekerja untuk membawa kebijakan antrean ke alur YAML, kami sarankan Anda menggunakan persetujuan manual untuk mengurutkan dan mengontrol urutan eksekusi secara manual jika ini penting.

Klasik

Dalam beberapa kasus, Anda mungkin dapat menghasilkan build lebih cepat daripada yang dapat disebarkan. Atau, Anda dapat mengonfigurasi beberapa agen dan, misalnya, membuat rilis dari alur rilis yang sama untuk penyebaran artefak yang berbeda. Dalam kasus seperti itu, berguna untuk dapat mengontrol bagaimana beberapa rilis diantrekan ke dalam tahap. Kebijakan antrean memberi Anda kontrol tersebut.

Opsi yang dapat Anda pilih untuk kebijakan antrean adalah:

• Jumlah penyebaran paralel: Gunakan opsi ini jika Anda secara dinamis menyediakan sumber daya baru dalam tahap Anda dan secara fisik mampu menangani penyebaran beberapa rilis secara paralel, tetapi Anda ingin membatasi jumlah penyebaran paralel.

• Jika Anda menentukan jumlah maksimum penyebaran, dua opsi lagi akan muncul:

  • Sebarkan semua secara berurutan: Gunakan opsi ini jika Anda ingin menyebarkan semua rilis secara berurutan ke sumber daya fisik bersama yang sama. Dengan menyebarkan build secara bergantian, satu demi satu, Anda memastikan bahwa dua pekerjaan penyebaran tidak menargetkan sumber daya fisik yang sama secara bersamaan, bahkan jika ada beberapa agen build dan rilis yang tersedia. Anda juga memastikan bahwa permintaan persetujuan pra-penyebaran untuk tahap dikirim secara berurutan.

  • Sebarkan yang terbaru dan batalkan yang lain: Gunakan opsi ini jika Anda memproduksi build lebih cepat daripada rilis, dan Anda hanya ingin menyebarkan build terbaru.

Untuk memahami cara kerja opsi ini, pertimbangkan skenario di mana rilis R1, R2, ..., R5 dari satu alur rilis dibuat secara berturut-turut. Asumsikan bahwa tahap pertama dalam alur ini diberi nama QA dan memiliki pemberi izin pra-penyebaran dan pasca-penyebaran yang ditentukan.

• Jika Anda tidak menentukan batas jumlah penyebaran paralel, kelima permintaan persetujuan dikirim segera setelah rilis dibuat. Jika pemberi persetujuan menyetujui semua rilis, mereka semua akan disebarkan ke tahap QA secara paralel. (jika Tahap QA tidak memiliki pemberi izin pra-penyebaran yang ditentukan, kelima rilis akan secara otomatis disebarkan secara paralel dengan tahap ini).

• Jika Anda menentukan batas dan Menyebarkan semua secara berurutan, dan batas telah tercapai, persetujuan pra-penyebaran untuk rilis R1 akan dikirim terlebih dahulu. Setelah persetujuan ini selesai, penyebaran rilis R1 ke tahap QA dimulai. Selanjutnya, permintaan persetujuan pasca-penyebaran dikirim untuk rilis R1. Hanya setelah persetujuan pasca-penyebaran ini selesai bahwa eksekusi rilis R2 dimulai dan persetujuan pra-penyebarannya dikirim. Proses berlanjut seperti ini untuk semua rilis secara bergantian.

• Jika Anda menentukan batas dan Menyebarkan yang terbaru dan membatalkan yang lain, dan batas telah tercapai, rilis R2, R3, dan R4 akan dilewati, dan persetujuan pra-penyebaran untuk R5 dalam tahap QA akan dikirim segera setelah persetujuan pasca-penyebaran untuk rilis R1 selesai.

Tentukan persetujuan

YAML

Anda dapat mengontrol secara manual kapan tahap harus berjalan menggunakan pemeriksaan persetujuan. Ini biasanya digunakan untuk mengontrol penyebaran ke lingkungan produksi. Pemeriksaan adalah mekanisme yang tersedia bagi pemilik sumber daya untuk mengontrol apakah dan kapan tahap dalam alur dapat menggunakan sumber daya. Sebagai pemilik sumber daya, seperti lingkungan, Anda dapat menentukan pemeriksaan yang harus dipenuhi sebelum tahap menggunakan sumber daya tersebut dapat dimulai.

Saat ini, pemeriksaan persetujuan manual didukung pada lingkungan. Untuk informasi selengkapnya, lihat Persetujuan.

Klasik

Anda dapat menambahkan persetujuan manual di awal atau akhir setiap tahap dalam alur. Untuk informasi selengkapnya, lihat Ringkasan persetujuan dan gerbang rilis.