Menambahkan tahapan, dependensi, dan kondisi

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

Tahap adalah batas logis dalam alur Azure DevOps. Tahapan tindakan grup dalam proses pengembangan perangkat lunak Anda, seperti membangun aplikasi, menjalankan pengujian, dan menyebarkan ke praproduksi. Setiap tahap berisi satu atau beberapa pekerjaan.

Saat Anda menentukan beberapa tahap dalam alur, secara otomatis, mereka dijalankan satu demi satu. Tahapan juga dapat bergantung satu sama lain. Anda dapat menggunakan dependsOn kata kunci untuk menentukan dependensi. Tahap-tahap 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 di alur kerja menjadi tahap-tahap. Tahap adalah pembagian utama dalam alur kerja: membangun aplikasi ini, menjalankan tes ini, dan menyebarkannya ke praproduksi adalah contoh yang baik dari tahap. 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. Panggung dapat memiliki hingga 256 pekerjaan.

Klasik

Atur pekerjaan penyebaran dalam alur rilis Anda ke dalam tahapan. Tahapan adalah divisi utama dalam alur rilis Anda. Contohnya termasuk menjalankan pengujian fungsional, menyebarkan ke praproduksi, dan menyebarkan ke produksi.

Tahap dalam alur rilis terdiri dari pekerjaan dan tugas.

Persetujuan dan gerbang, kondisi dan pemicu penyebaran, serta kebijakan antrean mengendalikan kapan rilis disebarkan ke tahap.

Tentukan tahapan

YAML

Dalam kasus paling sederhana, Anda tidak memerlukan batas logis di alur Anda. Untuk skenario tersebut, Anda dapat langsung menentukan pekerjaan dalam file YAML Anda tanpa stages kata kunci. Misalnya, jika Anda memiliki alur sederhana yang membangun dan menguji aplikasi kecil tanpa memerlukan lingkungan atau langkah penyebaran terpisah, Anda dapat menentukan semua pekerjaan secara langsung tanpa menggunakan tahapan.

pool:
  vmImage: 'ubuntu-latest'

jobs:
- job: BuildAndTest
  steps:
  - script: echo "Building the application"
  - script: echo "Running tests"

Alur ini memiliki satu tahap implisit dan dua pekerjaan. Kata stages kunci tidak digunakan karena hanya ada satu tahap.

jobs:
- job: Build
  steps:
  - bash: echo "Building"

- job: Test
  steps:
  - bash: echo "Testing"

Untuk menata alur Anda ke dalam beberapa tahap, gunakan stages kata kunci. YAML ini mendefinisikan alur dengan dua tahap di mana setiap tahap berisi beberapa pekerjaan, dan setiap pekerjaan memiliki langkah-langkah khusus untuk dijalankan.

stages:
- stage: A
  displayName: "Stage A - Build and Test"
  jobs:
  - job: A1
    displayName: "Job A1 - build"
    steps:
    - script: echo "Building the application in Job A1"
      displayName: "Build step"
  - job: A2
    displayName: "Job A2 - Test"
    steps:
    - script: echo "Running tests in Job A2"
      displayName: "Test step"

- stage: B
  displayName: "Stage B - Deploy"
  jobs:
  - job: B1
    displayName: "Job B1 - Deploy to Staging"
    steps:
    - script: echo "Deploying to staging in Job B1"
      displayName: "Staging deployment step"
  - job: B2
    displayName: "Job B2 - Deploy to Production"
    steps:
    - script: echo "Deploying to production in Job B2"
      displayName: "Production deployment step"

Jika Anda menentukan pool pada tingkat tahap, semua pekerjaan dalam tahap tersebut menggunakan kumpulan tersebut kecuali tahap 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

Klasik

Untuk menambahkan tahap ke alur rilis Anda, pilih alur rilis pada halaman Rilis, pilih Edit, 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 akan mendapatkan pemberitahuan setiap kali penyebaran ke tahap tersebut mengalami kegagalan. Kepemilikan panggung tidak secara otomatis memberikan izin.
• Hapus salah satu tahap dari alur kerja.
• 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, tahap tersebut berjalan secara berurutan secara default dalam urutan yang Anda tentukan dalam file YAML. Pengecualian untuk ini adalah ketika Anda menambahkan dependensi. Berdasarkan dependensi, tahapan berjalan sesuai urutan dependsOn persyaratan.

Alur harus berisi setidaknya satu tahap tanpa dependensi.

Untuk informasi selengkapnya tentang cara menentukan tahapan, lihat tahapan dalam skema YAML.

Contoh tahap berikut berjalan secara berurutan. Jika Anda tidak menggunakan dependsOn kata kunci, tahapan berjalan dalam urutan yang ditentukan.

stages:
- stage: Build
  displayName: "Build Stage"
  jobs:
  - job: BuildJob
    steps:
    - script: echo "Building the application"
      displayName: "Build Step"

- stage: Test
  displayName: "Test Stage"
  jobs:
  - job: TestJob
    steps:
    - script: echo "Running tests"
      displayName: "Test Step"

Contoh tahapan yang berjalan secara paralel:

stages:
- stage: FunctionalTest
  displayName: "Functional Test Stage"
  jobs:
  - job: FunctionalTestJob
    steps:
    - script: echo "Running functional tests"
      displayName: "Run Functional Tests"

- stage: AcceptanceTest
  displayName: "Acceptance Test Stage"
  dependsOn: [] # Runs in parallel with FunctionalTest
  jobs:
  - job: AcceptanceTestJob
    steps:
    - script: echo "Running acceptance tests"
      displayName: "Run Acceptance Tests"

Contoh perilaku fan-out dan fan-in:

stages:
- stage: Test

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

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

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

Klasik

Kontrol dependensi dengan mengatur pemicu pada setiap tahap alur rilis:

• Tahapan berjalan dengan pemicu atau dimulai secara manual.
• Dengan pemicu Setelah dirilis, tahapan dimulai segera setelah rilis dimulai, berjalan bersamaan dengan tahapan lain yang memiliki pemicu yang sama.
• Dengan pemicu tahap Setelah , tahap 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 bawaan, tahap berjalan jika tidak bergantung pada tahap lain, atau jika semua tahap yang bergantung padanya 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 ini tetap berjalan terlepas dari hasil tahap sebelumnya.

Catatan

Kondisi untuk gagal ('JOBNAME/STAGENAME') dan berhasil ('JOBNAME/STAGENAME') seperti yang ditunjukkan dalam contohnya hanya berfungsi untuk pipeline YAML.

YAML

Contoh menjalankan tahap berdasarkan status 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 khusus:

stages:
- stage: A

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

Klasik

Saat Anda menentukan Setelah rilis atau Setelah 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

Pipeline YAML tidak mendukung kebijakan antrean. Setiap eksekusi pada alur kerja berdiri sendiri dan tidak dipengaruhi oleh eksekusi lainnya. Dengan kata lain, dua commit berturut-turut Anda mungkin memicu dua pipeline, dan keduanya akan menjalankan urutan tahap yang sama persis tanpa saling menunggu. Meskipun kami bekerja untuk membawa kebijakan antrian ke alur YAML, kami sarankan Anda menggunakan persetujuan manual untuk mengurutkan dan mengontrol eksekusi secara manual jika ini penting.

Klasik

Dalam beberapa kasus, Anda mungkin dapat menghasilkan build lebih cepat daripada build tersebut 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 tersebut dikirim dalam urutan.

  • 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 ke 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. Eksekusi rilis R2 baru dimulai setelah persetujuan pasca-penyebaran ini selesai, dan persetujuan pra-penyebarannya dikirimkan. Proses ini berlanjut 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.

Spesifikasikan 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 secara manual didukung di lingkungan. Untuk informasi selengkapnya, lihat Persetujuan.

Klasik

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

Menambahkan pemicu manual

Tahapan alur YAML yang dipicu secara manual memungkinkan Anda memiliki alur terpadu tanpa selalu menjalankannya hingga selesai.

Misalnya, alur Anda mungkin mencakup tahapan untuk membangun, menguji, menyebarkan ke lingkungan penahapan, dan menyebarkan ke produksi. Anda mungkin ingin semua tahap berjalan otomatis, kecuali penyebaran produksi yang ingin Anda picu secara manual saat sudah siap.

Untuk menggunakan fitur ini, tambahkan properti trigger: manual ke suatu tahap.

Dalam contoh berikut, tahap pengembangan berjalan secara otomatis, sementara tahap produksi memerlukan pemicu manual. Kedua tahap menjalankan skrip yang menghasilkan output "hello world".

stages:
- stage: Development
  displayName: Deploy to development
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'
- stage: Production
  displayName: Deploy to production
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'

Menandai tahapan sebagai tidak dapat dilewati

Tandai tahap sebagai isSkippable: false untuk mencegah pengguna alur melewati tahapan. Misalnya, Anda mungkin memiliki templat YAML yang menyuntikkan tahap yang melakukan deteksi malware di semua alur. Jika Anda mengatur isSkippable: false untuk tahap ini, alur Anda tidak akan dapat melewati deteksi malware.

Dalam contoh berikut, tahap deteksi malware ditandai sebagai tidak dapat dilewati, yang berarti harus dijalankan sebagai bagian dari menjalankan alur.

- stage: malware_detection
  displayName: Malware detection
  isSkippable: false
  jobs:
  - job: check_job
    ...

Ketika tahap tidak dapat dilewati, tahap tersebut akan ditampilkan dengan kotak centang yang dinonaktifkan di panel konfigurasi Tahap yang dijalankan.