Pertanyaan bagus Saya tidak berpikir ada jawaban 'resmi' yang benar untuk ini. Itu tergantung seberapa cepat Anda bisa menguji.
Masalah penting adalah bahwa setiap penggabungan, kompilasi atau bahkan penyebaran, berpotensi dapat membuat bug. Semakin jauh 'naik' rantai yang Anda uji, semakin cepat Anda tahu tentang bug, tetapi juga semakin banyak kali Anda harus menguji ulang.
Untuk memastikan bahwa Anda telah menguji perangkat lunak yang digunakan pelanggan, Anda benar-benar harus menguji penyebaran langsung sebelum lalu lintas pelanggan (dengan asumsi aplikasi web) dialihkan ke server-server tersebut melalui pola penyebaran biru / hijau.
Tapi jelas ini agak terlambat untuk menjadi yang pertama kali Anda memeriksa kode sama sekali!
Jika Anda menguji cabang rilis dalam qa env maka Anda dapat mengambil risiko dan mengurangi pengujian langsung menjadi tes merokok saja. dan terapkan perbaikan bug ke cabang rilis. Tetapi Anda tidak dapat menilai apakah suatu fitur sudah lengkap sebelum membuat rilis
Jika Anda menguji pengembangan maka Anda mendapatkan cabang bug-fix-fitur mini. Fitur masih digabungkan sebelum dinilai, ditambah fitur untuk rilis berikutnya dapat bertabrakan dengan pengujian rilis saat ini.
Jika Anda menguji cabang Fitur, Anda memerlukan sejuta lingkungan dan harus mengatur urutan gabungan dan uji sign off. ditambah banyak pengujian ulang.
Dari pengalaman saya, saya akan merekomendasikan:
uji cepat cabang fitur pada mesin dev. cukup pastikan fitur-fiturnya lengkap dan penguji / pengembang setuju tentang apa arti persyaratan.
Pengujian sehari-hari / pengujian otomatis pada cabang dev yang digunakan untuk server qa. Memungkinkan Anda menguji semua fitur bersama dan mengatakan kapan Anda siap untuk merilis.
Jika semua fitur dalam tetapi pengujian belum selesai. misalnya sprint selesai. membuat cabang rilis dan menyebarkan ke lingkungan qa kedua. Hal ini memungkinkan untuk memperbaiki / menguji bug pada rilis 1 untuk melanjutkan pada saat yang sama dengan fitur untuk rilis 2.
(penggemar scrum akan mengatakan bahwa Anda hanya harus memasukkan perbaikan bug ke sprint 2 tetapi tetaplah praktis)
Tes asap pada penyebaran hijau / biru hidup sebelum beralih. Ini sangat penting karena Anda akan mengambil kesalahan konfigurasi / lingkungan yang tidak terlihat oleh siapa pun saat berkembang.