Menentukan persetujuan dan pemeriksaan

Azure DevOps

Alur terdiri dari tahapan. Penulis alur dapat mengontrol apakah tahap harus berjalan dengan menentukan kondisi di panggung. Cara lain untuk mengontrol apakah dan kapan tahap harus berjalan adalah melalui persetujuan dan pemeriksaan.

Alur mengandalkan sumber daya seperti lingkungan, koneksi layanan, kumpulan agen, grup variabel, dan file aman. Pemeriksaan memungkinkan pemilik sumber daya untuk mengontrol apakah dan kapan tahap dalam alur apa pun dapat menggunakan sumber daya. Sebagai pemilik sumber daya, Anda dapat menentukan pemeriksaan yang harus dipenuhi sebelum tahap mengkonsumsi sumber daya tersebut dapat dimulai. Misalnya, pemeriksaan persetujuan manual pada lingkungan akan memastikan bahwa penyebaran ke lingkungan tersebut hanya terjadi setelah pengguna yang ditunjuk telah meninjau perubahan yang disebarkan.

Tahap dapat terdiri dari banyak pekerjaan, dan setiap pekerjaan dapat menggunakan beberapa sumber daya. Sebelum eksekusi tahap dapat dimulai, semua pemeriksaan pada semua sumber daya yang digunakan dalam tahap itu harus dipenuhi. Azure Pipelines menjeda eksekusi alur sebelum setiap tahap, dan menunggu semua pemeriksaan tertunda selesai. Pemeriksaan dievaluasi ulang berdasarkan interval coba lagi yang ditentukan dalam setiap pemeriksaan. Jika semua pemeriksaan tidak berhasil sampai batas waktu yang ditentukan, maka tahap tersebut tidak dijalankan. Jika salah satu pemeriksaan gagal secara terminal (misalnya, jika Anda menolak persetujuan pada salah satu sumber daya), maka tahap tersebut tidak dijalankan.

Persetujuan dan pemeriksaan lainnya tidak ditentukan dalam file yaml. Pengguna yang memodifikasi file yaml alur tidak dapat mengubah pemeriksaan yang dilakukan sebelum memulai tahap. Administrator sumber daya mengelola pemeriksaan menggunakan antarmuka web Azure Pipelines.

Penting

Pemeriksaan dapat dikonfigurasi pada lingkungan, koneksi layanan, repositori, grup variabel, file aman, dan kumpulan agen.

Koneksi layanan tidak dapat ditentukan oleh variabel.

Persetujuan

Anda dapat mengontrol secara manual kapan tahap harus berjalan menggunakan pemeriksaan persetujuan. Ini biasanya digunakan untuk mengontrol penyebaran ke lingkungan produksi.

1. Dalam proyek Azure DevOps Anda, buka sumber daya (misalnya lingkungan) yang perlu dilindungi.

2. Nagivasi Persetujuan dan Pemeriksaan untuk sumber daya.

3. Pilih Buat, berikan pemberi persetujuan dan pesan opsional, dan pilih Buat lagi untuk menyelesaikan penambahan pemeriksaan persetujuan manual.

Anda dapat menambahkan beberapa pemberi izin ke lingkungan. Pemberi izin ini dapat berupa pengguna individu atau grup pengguna. Saat grup ditentukan sebagai pemberi izin, hanya salah satu pengguna dalam grup tersebut yang perlu menyetujui eksekusi untuk maju.

Dengan menggunakan opsi tingkat lanjut, Anda dapat mengonfigurasi jumlah minimum pemberi persetujuan untuk menyelesaikan persetujuan. Grup dianggap sebagai satu pemberi izin.

Anda juga dapat membatasi pengguna yang meminta (memulai atau membuat) eksekusi agar tidak menyelesaikan persetujuan. Opsi ini umumnya digunakan untuk pemisahan peran di antara pengguna.

Saat Anda menjalankan alur, eksekusi eksekusi tersebut berhenti sejenak sebelum memasuki tahap yang menggunakan lingkungan. Pengguna yang dikonfigurasi sebagai pemberi persetujuan harus meninjau dan menyetujui atau menolak penyebaran. Jika Anda memiliki beberapa eksekusi yang dijalankan secara bersamaan, Anda harus menyetujui atau menolak masing-masing eksekusi secara independen. Jika semua persetujuan yang diperlukan tidak selesai dalam Batas Waktu yang ditentukan untuk persetujuan dan semua pemeriksaan lainnya berhasil, tahap ditandai dilewati.

Kontrol cabang

Dengan menggunakan pemeriksaan kontrol cabang, Anda dapat memastikan semua sumber daya yang terkait dengan alur dibangun dari cabang yang diizinkan dan bahwa cabang telah mengaktifkan perlindungan. Ini membantu dalam mengontrol kesiapan rilis dan kualitas penyebaran. Jika beberapa sumber daya ditautkan dengan alur, sumber untuk semua sumber daya diverifikasi. Jika Anda telah menautkan alur lain, maka cabang eksekusi tertentu yang disebarkan diverifikasi untuk perlindungan.

Untuk menentukan pemeriksaan kontrol cabang:

1. Dalam proyek Azure DevOps Anda, buka sumber daya (misalnya lingkungan) yang perlu dilindungi.

2. Nagivasi Persetujuan dan Pemeriksaan untuk sumber daya.

3. Pilih pemeriksaan Kontrol cabang dan berikan daftar cabang yang diizinkan yang dipisahkan koma. Anda dapat mengamanatkan bahwa cabang harus mengaktifkan perlindungan dan perilaku status perlindungan kasus check-in untuk salah satu cabang tidak diketahui.

Pada durasi, pemeriksaan akan memvalidasi cabang untuk semua sumber daya tertaut dalam eksekusi terhadap daftar yang diizinkan. Jika salah satu cabang tidak cocok dengan kriteria, pemeriksaan gagal dan tahap ditandai gagal.

Catatan

Pemeriksaan ini mengharuskan nama cabang sepenuhnya memenuhi syarat. Pastikan format untuk nama cabang adalah refs/heads/<branch name>

Jam kerja

Jika Anda ingin semua penyebaran ke lingkungan Anda terjadi hanya di jendela waktu tertentu, maka pemeriksaan jam kerja adalah solusi yang ideal. Saat Anda menjalankan alur, eksekusi tahap yang menggunakan sumber daya menunggu jam kerja. Jika Anda memiliki beberapa eksekusi yang dijalankan secara bersamaan, masing-masing diverifikasi secara independen. Pada awal jam kerja, pemeriksaan ditandai berhasil untuk semua eksekusi.

Jika eksekusi tahap belum dimulai pada akhir jam kerja (ditahan oleh beberapa pemeriksaan lain), persetujuan jam kerja secara otomatis ditarik dan evaluasi ulang dijadwalkan untuk hari berikutnya. Pemeriksaan gagal jika eksekusi tahap tidak dimulai dalam periode Batas Waktu yang ditentukan untuk pemeriksaan, dan tahap ditandai gagal.

Memanggil fungsi Azure

Fungsi Azure adalah platform komputasi tanpa server yang ditawarkan oleh Azure. Dengan fungsi Azure, Anda dapat menjalankan potongan kecil kode (disebut "fungsi") tanpa khawatir tentang infrastruktur aplikasi. Mengingat fleksibilitas tinggi, fungsi Azure memberikan cara yang bagus untuk menulis pemeriksaan Anda sendiri. Anda menyertakan logika fungsi Azure check-in sehingga setiap eksekusi dipicu pada permintaan http, memiliki waktu eksekusi singkat dan mengembalikan respons. Saat menentukan pemeriksaan, Anda dapat mengurai isi respons untuk menyimpulkan apakah pemeriksaan berhasil. Evaluasi dapat diulang secara berkala menggunakan pengaturan Waktu antara evaluasi dalam opsi kontrol. Pelajari Selengkapnya

Pemeriksaan gagal jika tahap belum memulai eksekusi dalam periode Batas Waktu yang ditentukan. Lihat Tugas Aplikasi Fungsi Azure untuk detail selengkapnya.

Catatan

Variabel alur yang ditentukan pengguna tidak dapat diakses ke pemeriksaan. Anda hanya dapat mengakses variabel dan variabel yang telah ditentukan sebelumnya dari grup variabel tertaut dalam isi permintaan.

Memanggil REST API

Memanggil pemeriksaan REST API memungkinkan Anda untuk berintegrasi dengan salah satu layanan yang ada. Secara berkala, lakukan panggilan ke REST API dan lanjutkan jika mengembalikan respons yang berhasil. Pelajari Selengkapnya

Evaluasi dapat diulang secara berkala menggunakan pengaturan Waktu antara evaluasi dalam opsi kontrol. Pemeriksaan gagal jika tahap belum memulai eksekusi dalam periode Batas Waktu yang ditentukan. Lihat Memanggil tugas REST API untuk detail selengkapnya.

Catatan

Variabel alur yang ditentukan pengguna tidak dapat diakses ke pemeriksaan. Anda hanya dapat mengakses variabel dan variabel yang telah ditentukan sebelumnya dari grup variabel tertaut dalam isi permintaan.

Mengkueri Pemberitahuan Azure Monitor

Azure Monitor menawarkan visualisasi, kueri, perutean, pemberitahuan, skala otomatis, dan otomatisasi pada data dari infrastruktur Azure dan setiap sumber daya Azure individual. Pemberitahuan adalah sarana standar untuk mendeteksi masalah dengan kesehatan infrastruktur atau aplikasi, dan mengambil tindakan korektif. Penyebaran kenari dan peluncuran bertahap adalah strategi penyebaran umum yang digunakan untuk menurunkan risiko regresi ke aplikasi penting. Setelah menyebarkan ke tahap (sekumpulan pelanggan), aplikasi diamati untuk jangka waktu tertentu. Kesehatan aplikasi setelah penyebaran digunakan untuk memutuskan apakah pembaruan harus dilakukan ke tahap berikutnya atau tidak.

Pemberitahuan Azure Monitor Kueri membantu Anda mengamati Azure Monitor dan memastikan tidak ada pemberitahuan yang dimunculkan untuk aplikasi setelah penyebaran. Pemeriksaan berhasil jika tidak ada aturan pemberitahuan yang diaktifkan pada saat evaluasi. Pelajari Selengkapnya

Evaluasi diulang setelah Waktu antara pengaturan evaluasi dalam opsi kontrol. Pemeriksaan gagal jika tahap belum memulai eksekusi dalam periode Batas Waktu yang ditentukan.

Templat yang diperlukan

Dengan pemeriksaan templat yang diperlukan, Anda dapat memberlakukan alur untuk menggunakan templat YAML tertentu. Ketika pemeriksaan ini diberlakukan, alur akan gagal jika tidak diperluas dari templat yang dirujuk.

Untuk menentukan persetujuan templat yang diperlukan:

1. Di proyek Azure DevOps Anda, buka koneksi layanan yang ingin Anda batasi.

2. Buka Persetujuan dan Pemeriksaan di menu di samping Edit.

3. Di menu centang Tambahkan pertama Anda , pilih Templat yang diperlukan.

4. Masukkan detail tentang cara masuk ke file templat yang diperlukan.

   • Jenis repositori: Lokasi repositori Anda (GitHub, Azure, atau Bitbucket).
   • Repositori: Nama repositori Anda yang berisi templat Anda.
   • Ref: Cabang atau tag templat yang diperlukan.
   • Jalur ke templat yang diperlukan: Nama templat Anda.

Anda dapat memiliki beberapa templat yang diperlukan untuk koneksi layanan yang sama. Dalam contoh ini, templat yang diperlukan adalah required.yml.

Mengevaluasi artefak

Anda dapat mengevaluasi artefak yang akan disebarkan ke lingkungan terhadap kebijakan kustom.

Catatan

Saat ini, ini hanya berfungsi dengan artefak gambar kontainer

Untuk menentukan evaluasi kebijakan kustom atas artefak, ikuti langkah-langkah di bawah ini.

1. Dalam proyek Azure DevOps Services Anda, navigasikan ke lingkungan yang perlu dilindungi. Pelajari selengkapnya tentang membuat lingkungan.

2. Navigasikan ke Persetujuan dan periksa lingkungan.

3. Pilih Evaluasi artefak.

4. Tempel definisi kebijakan dan klik Simpan. Lihat selengkapnya tentang menulis definisi kebijakan.

Saat Anda menjalankan alur, eksekusi eksekusi tersebut berhenti sejenak sebelum memasuki tahap yang menggunakan lingkungan. Kebijakan yang ditentukan dievaluasi terhadap metadata gambar yang tersedia. Pemeriksaan lolos ketika kebijakan berhasil dan gagal sebaliknya. Tahap ditandai gagal jika pemeriksaan gagal.

Lulus

Anda juga dapat melihat log lengkap pemeriksaan kebijakan dari tampilan alur.

Gagal

Anda juga dapat melihat log lengkap pemeriksaan kebijakan dari tampilan alur.

Kunci eksklusif

Pemeriksaan kunci eksklusif hanya memungkinkan satu eksekusi dari alur untuk melanjutkan. Semua tahapan dalam semua eksekusi alur yang menggunakan sumber daya dijeda. Ketika tahap menggunakan kunci selesai, maka tahap lain dapat melanjutkan untuk menggunakan sumber daya. Selain itu, hanya satu tahap yang akan diizinkan untuk melanjutkan.

Perilaku tahapan lain yang mencoba mengambil kunci dikonfigurasi oleh lockBehavior nilai yang dikonfigurasi dalam file YAML untuk alur.

• runLatest - Hanya eksekusi terbaru yang memperoleh kunci ke sumber daya. runLatest adalah default jika tidak lockBehavior ada yang ditentukan.
• sequential - Semua eksekusi memperoleh kunci secara berurutan ke sumber daya yang dilindungi.

Untuk menggunakan pemeriksaan kunci eksklusif dengan sequential penyebaran atau runLatest, ikuti langkah-langkah berikut:

1. Aktifkan pemeriksaan kunci eksklusif pada lingkungan (atau sumber daya lain yang dilindungi).
2. Dalam file YAML untuk alur, tentukan properti yang disebut lockBehavior. Ini dapat ditentukan untuk seluruh alur atau untuk tahap tertentu:

Atur pada panggung:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Atur pada alur:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Jika Anda tidak menentukan lockBehavior, nilai default digunakan runLatest .

Pemeriksaan kunci eksklusif hanya memungkinkan satu eksekusi dari alur untuk melanjutkan. Semua tahapan dalam semua eksekusi alur yang menggunakan sumber daya dijeda. Ketika tahap menggunakan kunci selesai, maka tahap lain dapat melanjutkan untuk menggunakan sumber daya. Selain itu, hanya satu tahap yang akan diizinkan untuk melanjutkan. Tahapan lain yang mencoba mengambil kunci akan dibatalkan.

Manajemen Perubahan ServiceNow

Pemeriksaan ini memerlukan ekstensi Manajemen Perubahan ServiceNow untuk diinstal dari marketplace

Pemeriksaan manajemen perubahan servicenow memungkinkan integrasi proses manajemen perubahan ServiceNow dalam alur. Dengan menambahkan pemeriksaan, permintaan perubahan baru di ServiceNow dapat dibuat secara otomatis di awal tahap. Alur menunggu proses perubahan selesai sebelum memulai tahap. Detail lebih lanjut tersedia di sini.

FAQ

Pemeriksaan yang ditentukan tidak dimulai. Apa yang terjadi?

Evaluasi pemeriksaan dimulai setelah kondisi tahapan terpenuhi. Anda harus mengonfirmasi eksekusi tahap dimulai setelah pemeriksaan ditambahkan pada sumber daya dan bahwa sumber daya dikonsumsi dalam tahap.

Bagaimana cara menggunakan pemeriksaan untuk menjadwalkan tahapan?

Dengan menggunakan pemeriksaan jam kerja, Anda dapat mengontrol waktu untuk memulai eksekusi tahap. Anda dapat mencapai perilaku yang sama dengan jadwal yang telah ditentukan sebelumnya pada tahap dalam rilis perancang.

Bagaimana cara mengambil persetujuan terlebih dahulu untuk tahap yang dijadwalkan untuk dijalankan di masa mendatang?

Skenario ini dapat diaktifkan

1. Pemeriksaan jam kerja memungkinkan semua tahapan yang disebarkan ke sumber daya untuk dijadwalkan untuk eksekusi antara jendela waktu
2. Ketika persetujuan dikonfigurasi pada sumber daya yang sama, tahap akan menunggu persetujuan sebelum memulai.
3. Anda dapat mengonfigurasi kedua pemeriksaan pada sumber daya. Panggung akan menunggu persetujuan dan jam kerja. Ini akan dimulai di jendela terjadwal berikutnya setelah persetujuan selesai.

Dapatkah saya menunggu penyelesaian pemindaian keamanan pada artefak yang disebarkan?

Untuk menunggu penyelesaian pemindaian keamanan pada artefak yang disebarkan, Anda harus menggunakan layanan pemindaian eksternal seperti AquaScan. Artefak yang disebarkan perlu diunggah di lokasi yang dapat diakses oleh layanan pemindaian sebelum dimulainya pemeriksaan, dan dapat diidentifikasi menggunakan variabel yang telah ditentukan sebelumnya. Dengan menggunakan pemeriksaan Panggil REST API, Anda dapat menambahkan pemeriksaan untuk menunggu API di layanan keamanan dan meneruskan pengidentifikasi artefak sebagai input.

Bagaimana cara menggunakan variabel output dari tahap sebelumnya dalam pemeriksaan?

Secara default, hanya variabel yang telah ditentukan sebelumnya yang tersedia untuk diperiksa. Anda dapat menggunakan grup variabel tertaut untuk mengakses variabel lain. Variabel output dari tahap sebelumnya dapat ditulis ke grup variabel dan diakses dalam pemeriksaan.