Pilih titik saat Taiga menunggu keputusan

Pisahkan empat keputusan

Layanan peralatan fiktif memiliki empat keputusan berbeda: menerima rencana, menjalankan build, melakukan merge perubahan, dan melakukan deployment. Jangan perlakukan satu tombol sebagai otorisasi untuk keempatnya.

Sebelum mengubah otonomi, periksa tindakan pipeline repositori setelah merge. Jika merge ke branch kerja memicu deployment, merge otomatis juga dapat memicu alur kerja yang sudah ada tersebut.

Tentukan apakah rencana harus menunggu

Pengaturan produk Build on its own by default mengontrol apakah rencana yang selesai langsung berlanjut ke build atau menunggu persetujuan. Nonaktifkan ketika rencana memerlukan keputusan manusia terlebih dahulu.

Pengaturan Build on its own pada inisiatif dapat mengubah perilaku tersebut untuk inisiatif itu. Periksa pengaturan default dan pilihan khusus sebelum memasukkan pekerjaan ke antrean.

Approve memulai build atas nama orang yang menyetujui, sesuai izin yang dimilikinya saat itu. Rencana yang gagal tidak memulai build. Otomatisasi build tidak dengan sendirinya mengizinkan merge pull request yang dihasilkan.

Pahami hierarki merge

Merge otonom dikontrol secara terpisah dan tetap nonaktif sampai diaktifkan. Integrasi yang didokumentasikan mendukung GitHub, termasuk GitHub Enterprise.

Batas organisasi atau factory yang dinonaktifkan tidak dapat dikesampingkan di tingkat bawahnya. Pengaturan default produk yang nonaktif berbeda: inisiatif dapat mengaktifkan merge-nya sendiri jika batas izin memperbolehkan.

Untuk layanan peralatan, nyatakan cakupan awal secara eksplisit. Satu inisiatif berdampak rendah dapat memiliki pilihan berbeda dari perubahan kontrol akses karyawan, selama tetap dalam batas yang diizinkan.

Buat peninjauan wajib dapat ditegakkan

Taiga menanyakan kepada penyedia kontrol kode sumber apakah pull request boleh di-merge. Perlindungan branch menentukan pemeriksaan wajib, peninjauan, dan syarat lain. Merge otonom tidak melewati aturan tersebut.

Jika peninjauan otomatis harus memblokir merge, jadikan hasilnya pemeriksaan status wajib melalui konfigurasi yang didukung repositori. Hasil yang hanya bersifat saran tidak menjadi wajib karena Anda mengharapkannya demikian.

Periksa juga persetujuan manusia yang diwajibkan. Pemeriksaan hijau bukan pengganti persetujuan yang diwajibkan kebijakan. Konfirmasikan aturan pada branch target yang sebenarnya.

Tafsirkan merge yang berhenti

Baca alasannya pada inisiatif. Pemeriksaan tertunda, persetujuan yang belum ada, konflik, dan rencana yang belum lengkap memerlukan respons berbeda. Taiga juga menghentikan merge otonom ketika perbaikan mengubah kriteria sehingga pemeriksaan yang semula gagal menjadi lulus. Tinjau perubahan tersebut secara langsung.

Jangan hapus pemeriksaan wajib hanya karena menghambat kemajuan. Jika pemeriksaan tidak pernah melaporkan hasil, perbaiki konfigurasinya atau gunakan proses kebijakan yang diizinkan. Periksa commit saat ini setelah setiap perbaikan.

Pisahkan otorisasi deployment

Taiga GitHub App melakukan merge otonom dan dicatat sebagai pelaku merge. Pipeline repositori mempertahankan perilaku deployment yang sudah ada.

Dalam skenario ini, merge melakukan deployment ke staging. Produksi tetap memerlukan keputusan produksi organisasi dan bukti. Konfirmasikan bahwa pipeline menegakkan pemisahan ini. Lanjutkan ke peninjauan pengiriman.