Menentukan persetujuan dan pemeriksaan

Azure DevOps

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

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.

Alur mengandalkan sumber daya seperti lingkungan, koneksi layanan, kumpulan agen, grup variabel, dan file aman. Pemeriksaan memungkinkan pemilik sumber daya 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 menggunakan sumber daya tersebut dapat dimulai. Misalnya, pemeriksaan persetujuan manual pada lingkungan memastikan bahwa penyebaran ke lingkungan tersebut hanya terjadi setelah pengguna yang ditunjuk 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 yang tertunda selesai.

Ada lima kategori persetujuan dan pemeriksaan dan mereka berjalan dalam urutan pembuatannya dalam setiap kategori. 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.

Anda dapat mencoba kembali tahap saat persetujuan dan waktu pemeriksaan habis.

Pemeriksaan statis berjalan terlebih dahulu lalu pra-pemeriksaan persetujuan dijalankan. Kategori secara berurutan adalah:

1. Pemeriksaan statis: Kontrol cabang, Templat yang diperlukan, dan Evaluasi artefak
2. Persetujuan pra-pemeriksaan
3. Pemeriksaan dinamis: Persetujuan, Panggil Azure Function, Panggil REST API, Jam Kerja, Kueri pemberitahuan Azure Monitor
4. Persetujuan pasca-pemeriksaan
5. Kunci eksklusif

Anda juga dapat melihat urutan eksekusi pada tab Persetujuan dan pemeriksaan .

Penting

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

Koneksi layanan tidak dapat ditentukan oleh variabel.

Approvals

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

1. Masuk ke organisasi Azure DevOps Anda, lalu navigasikan ke proyek Anda.

2. Pilih Lingkungan Alur>, lalu pilih lingkungan Anda.

3. Pilih tab Persetujuan dan pemeriksaan , lalu pilih + tanda untuk menambahkan pemeriksaan baru.

   

4. Pilih Persetujuan, lalu pilih Berikutnya.

5. Tambahkan pengguna atau grup sebagai Pemberi Persetujuan yang Ditunjuk, dan, jika diinginkan, berikan instruksi untuk pemberi persetujuan. Tentukan apakah Anda ingin mengizinkan atau membatasi pemberi persetujuan menyetujui eksekusi mereka sendiri, dan tentukan Batas Waktu yang Anda inginkan. Jika persetujuan tidak selesai dalam Batas Waktu yang ditentukan, tahap ditandai sebagai dilewati.

6. Pilih Buat setelah selesai.

   

7. Setelah pemeriksaan persetujuan dipicu, jendela perintah, seperti yang ditunjukkan dalam contoh berikut, disajikan di antarmuka pengguna. Jendela ini menyediakan opsi bagi pemberi persetujuan untuk menolak atau menyetujui eksekusi, bersama dengan instruksi yang menyertainya.

   

Daftar pengguna yang dapat meninjau Persetujuan diperbaiki pada saat persetujuan & pemeriksaan mulai berjalan. Artinya, perubahan pada daftar pengguna dan grup pemeriksaan persetujuan yang dilakukan setelah pemeriksaan mulai dijalankan tidak diambil.

Catatan

Jika grup ditetapkan sebagai pemberi persetujuan, hanya satu pengguna dalam grup yang perlu menyetujui eksekusi untuk melanjutkan.

Persetujuan yang ditangguhkan

Ada situasi ketika waktu ketika persetujuan diberikan dan waktu penyebaran harus dimulai tidak cocok. Misalnya, Anda mungkin ingin menunggu untuk menyebarkan rilis baru hingga waktu lalu lintas rendah di malam hari.

Untuk mengatasi skenario ini, Anda dapat menunda persetujuan dan mengatur waktu persetujuan menjadi efektif.

1. Pilih Tangguhkan persetujuan.

   

2. Atur waktu persetujuan.

   

Anda akan melihat persetujuan di panel Pemeriksaan sebagai pra-persetujuan. Persetujuan berlaku pada waktu yang ditetapkan.

Kontrol cabang

Dengan menggunakan pemeriksaan kontrol cabang, Anda dapat memastikan semua sumber daya yang ditautkan dengan alur dibangun dari cabang yang diizinkan dan bahwa cabang mengaktifkan perlindungan. Pemeriksaan 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. Anda juga dapat menentukan perilaku pemeriksaan apakah status perlindungan untuk salah satu cabang tidak diketahui. Cabang dianggap dilindungi jika setidaknya satu kebijakan telah diterapkan (termasuk kebijakan yang diterapkan di tingkat repositori).

   

Pada waktu proses, 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 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 sebagai gagal.

Memanggil fungsi Azure

Fungsi Azure adalah platform komputasi tanpa server yang ditawarkan oleh Azure. Dengan fungsi Azure, Anda dapat menjalankan potongan-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 jika pemeriksaan berhasil. Evaluasi dapat diulang secara berkala menggunakan pengaturan Waktu antara evaluasi dalam opsi kontrol. Pelajari Selengkapnya

Jika pemeriksaan Anda tidak berhasil dalam Batas Waktu yang dikonfigurasi, tahap terkait akan dilewati. Tahapan tergantung pada itu dilewati juga. Untuk informasi selengkapnya, lihat tugas Aplikasi Fungsi Azure.

Catatan

Variabel alur yang ditentukan pengguna dapat diakses oleh pemeriksaan yang dimulai dengan Sprint 215.

Baca selengkapnya tentang cara yang direkomendasikan untuk menggunakan pemeriksaan fungsi Azure. Pemeriksaan perlu mengikuti aturan tertentu tergantung pada modenya dan jumlah percobaan ulang yang harus mematuhinya.

Panggil 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. Jika pemeriksaan Anda tidak berhasil dalam Batas Waktu yang dikonfigurasi, tahap terkait akan dilewati. Tahapan tergantung pada itu dilewati juga. Untuk informasi selengkapnya, lihat Memanggil tugas REST API.

Catatan

Variabel alur yang ditentukan pengguna dapat diakses oleh pemeriksaan yang dimulai dengan Sprint 215.

Baca selengkapnya tentang cara yang disarankan untuk menggunakan pemeriksaan REST API pemanggilan.

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 dinaikkan 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 menerapkan alur untuk menggunakan templat YAML tertentu. Ketika pemeriksaan ini diberlakukan, alur 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 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 production_template.yaml.

Menonaktifkan pemeriksaan

Saat men-debug pemeriksaan, Anda mungkin ingin menonaktifkan sementara lalu mengaktifkannya lagi. Untuk menonaktifkan atau mengaktifkan pemeriksaan:

1. Di proyek Azure DevOps Anda, buka sumber daya dengan pemeriksaan.

2. Buka tab Persetujuan dan Pemeriksaan .

3. Di menu kontekstual, pilih Nonaktifkan atau Aktifkan.

   

Melewati pemeriksaan

Dalam beberapa keadaan seperti penyebaran perbaikan, Anda mungkin perlu melewati pemeriksaan. Anda hanya dapat melewati pemeriksaan hanya jika Anda memiliki izin administrator untuk sumber daya tempat pemeriksaan ditentukan.

Untuk melewati persetujuan, jam kerja, memanggil fungsi Azure, atau memanggil pemeriksaan REST API, pilih Lewati pemeriksaan saat sumber daya menunggu peninjauan. Berikut adalah contoh melewati pemeriksaan jam kerja.

Saat melewati pemeriksaan, Anda akan melihat siapa yang melewati pemeriksaan di panel pemeriksaan.

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. Navigasi ke Persetujuan dan periksa lingkungan.

   

3. Pilih Evaluasi artefak.

   

4. Tempelkan definisi kebijakan dan pilih 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 jika tidak. 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 dan dapat diatur pada tingkat tahap atau alur. 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 diizinkan untuk melanjutkan.

Properti lockBehavior menentukan bagaimana tahapan lain menangani kunci. Saat Anda menentukan lockBehavior properti untuk tahap, kunci secara otomatis dibuat untuk tahap tersebut. Ada dua nilai yang mungkin lockBehavior :

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

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). Opsi kunci eksklusif adalah pemeriksaan yang tersedia.

   

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 dan kunci diatur pada sumber daya, nilai runLatest default digunakan.

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 pada awal tahap. Alur menunggu proses perubahan selesai sebelum memulai tahap. Detail lebih lanjut tersedia di sini.

Beberapa Persetujuan dan Pemeriksaan

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 yang tertunda selesai.

Satu keputusan negatif akhir menyebabkan alur ditolak aksesnya dan tahap gagal. Keputusan semua persetujuan dan pemeriksaan kecuali untuk memanggil fungsi Azure / REST API dan Kunci eksklusif bersifat final. Anda dapat menjalankan ulang pemeriksaan fungsi Azure/REST API yang berhasil.

Saat menggunakan pemeriksaan fungsi Azure / REST API dengan cara yang disarankan, keputusan akses mereka juga final.

Saat Anda menentukan Waktu antara evaluasi untuk memanggil pemeriksaan fungsi Azure/REST API menjadi bukan nol, keputusan pemeriksaan bersifat non-final. Skenario ini patut dieksploitasi.

Mari kita lihat contohnya. Bayangkan alur YAML Anda memiliki tahap yang menggunakan koneksi layanan. Koneksi layanan ini memiliki dua pemeriksaan yang dikonfigurasi untuk itu:

1. Pemeriksaan asinkron, bernama Persetujuan Eksternal Diberikan, yang memverifikasi bahwa persetujuan eksternal diberikan dan dikonfigurasi dengan cara yang direkomendasikan.
2. Pemeriksaan sinkron, bernama Alasan Penyebaran Valid, yang memverifikasi bahwa alasan penyebaran valid dan yang Anda atur Waktu antara evaluasi menjadi 7 menit.

Kemungkinan eksekusi pemeriksaan diperlihatkan dalam diagram berikut.

Dalam eksekusi ini:

• Kedua pemeriksaan, Persetujuan Eksternal yang Diberikan dan Alasan Penyebaran Valid, dipanggil secara bersamaan. Alasan Penyebaran Valid segera gagal, tetapi karena Persetujuan Eksternal yang Diberikan tertunda , itu dicoba kembali.
• Pada menit 7, Alasan Penyebaran Valid dicoba kembali dan kali ini berlalu.
• Pada menit 15, Persetujuan Eksternal Yang Diberikan memanggil kembali ke Azure Pipelines dengan keputusan yang berhasil. Sekarang, kedua pemeriksaan lolos, sehingga alur diizinkan untuk terus menyebarkan tahap.

Mari kita lihat contoh lain, yang melibatkan dua pemeriksaan sinkron. Asumsikan alur YAML Anda memiliki tahap yang menggunakan koneksi layanan. Koneksi layanan ini memiliki dua pemeriksaan yang dikonfigurasi untuk itu:

1. Pemeriksaan sinkron, bernama Sinkronkan Pemeriksaan 1, yang Anda atur Waktu antara evaluasi menjadi 5 menit.
2. Pemeriksaan sinkron, bernama Sync Check 2, yang Anda atur Waktu antara evaluasi menjadi 7 menit.

Kemungkinan eksekusi pemeriksaan diperlihatkan dalam diagram berikut.

Dalam eksekusi ini:

• Kedua pemeriksaan, Sync Check 1 dan Sync Check 2, dipanggil secara bersamaan. Sinkronkan Pemeriksaan 1 lolos, tetapi dicoba kembali, karena Pemeriksaan Sinkronisasi 2 gagal.
• Pada menit 5, Sinkronkan Pemeriksaan 1 dicoba kembali tetapi gagal, sehingga dicoba kembali.
• Pada menit 7, Sync Check 2 dicoba kembali dan berhasil. Keputusan pass berlaku selama 7 menit. Jika Pemeriksaan Sinkronisasi 1 tidak lulus dalam interval waktu ini, Sync Check 2 akan dicoba kembali.
• Pada menit 10, Pemeriksaan Sinkronisasi 1 dicoba kembali tetapi gagal, sehingga dicoba kembali.
• Pada menit 14, Sync Check 2 dicoba kembali dan berhasil. Keputusan pass berlaku selama 7 menit. Jika Pemeriksaan Sinkronisasi 1 tidak lulus dalam interval waktu ini, Sync Check 2 akan dicoba kembali.
• Pada menit 15, Sync Check 1 dicoba kembali dan berhasil. Sekarang, kedua pemeriksaan lolos, sehingga alur diizinkan untuk terus menyebarkan tahap.

Mari kita lihat contoh yang melibatkan persetujuan dan pemeriksaan sinkron. Bayangkan Anda mengonfigurasi pemeriksaan sinkron dan persetujuan untuk koneksi layanan dengan Waktu antara evaluasi 5 menit. Hingga persetujuan diberikan, pemeriksaan Anda berjalan setiap 5 menit, terlepas dari keputusan.

FAQ

Pemeriksaan yang ditentukan tidak dimulai. Apa yang terjadi?

Evaluasi pemeriksaan dimulai setelah kondisi tahap 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 tahap?

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 panggung dalam rilis desainer.

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 awal pemeriksaan, dan dapat diidentifikasi menggunakan variabel yang telah ditentukan sebelumnya. Dengan menggunakan pemeriksaan Invoke 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 default 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.

Pelajari lebih lanjut

• Memanggil pemeriksaan Azure Function / REST API
• Rest API Persetujuan dan Pemeriksaan
• Rest API Kueri Persetujuan