Seorang kolega saya mengatakan kepada saya bahwa ia berpikir untuk membuat server CI kami untuk mengembalikan komit yang gagal dibangun, sehingga HEAD
in master
selalu stabil (seperti melewati setidaknya build).
Apakah ini praktik terbaik atau mungkin lebih bermasalah daripada hanya membiarkannya master
rusak sampai pengembang memperbaikinya?
Pemikiran saya adalah bahwa mengembalikan komit akan membuat tugas pembacaan komit dan perbaikan menjadi lebih kompleks (pengembang harus mengembalikan revert dan kemudian melakukan perbaikan, yang juga akan mengacaukan git log
) dan kita harus meninggalkan komit dan kemudian komit memperbaiki. Meskipun saya melihat beberapa keuntungan dalam memiliki master
stabil, kembalinya komitmen yang gagal ini tidak meyakinkan saya.
edit: Tidak masalah apakah itu master
atau cabang pengembangan lainnya, tetapi pertanyaannya tetap sama: haruskah sistem CI mengembalikan komit yang gagal dibangun?
sunting (lenghty) lain: Ok, kami menggunakan git
cara yang aneh. Kami percaya bahwa konsep cabang bertentangan dengan CI nyata, karena berkomitmen untuk cabang mengisolasi Anda dari pengembang lain dan perubahannya, dan menambah waktu ketika Anda harus mengintegrasikan kembali cabang Anda dan menangani kemungkinan konflik. Jika semua orang berkomitmen untuk master
konflik ini dikurangi seminimal mungkin dan setiap komit melewati semua tes.
Tentu saja, ini memaksa Anda untuk mendorong hanya stabil (atau Anda melanggar build) dan program lebih hati-hati untuk tidak merusak kompatibilitas atau melakukan fitur-toggling ketika memperkenalkan fitur baru.
Ada pengorbanan ketika melakukan CI ini atau itu, tetapi itu di luar ruang lingkup pertanyaan (lihat pertanyaan terkait untuk ini). Jika Anda suka, saya dapat menulis ulang pertanyaan: tim kecil pengembang bekerja sama dalam cabang fitur. Jika satu pengembang melakukan sesuatu yang merusak build untuk cabang itu, haruskah sistem CI mengembalikan komit atau tidak?
master
awal. Untuk itulah pengembangan & cabang fitur digunakan. Perubahan itu kemudian dalam sesuatu seperti cabang integrasi di mana Anda dapat menguji apakah semua fitur baru dari beberapa pengembang akan bekerja bersama dan hanya jika ini diuji dapat masuk ke master. Atau setidaknya itu satu alur kerja yang mungkin.