Masalah
Saya sedang mengerjakan proyek perangkat lunak yang memiliki sekitar 10 pengembang, kami membagikan kode sumber melalui Mercurial. Kami memiliki cabang pengembangan dan produksi per rilis. Berulang kali selama proyek kami memiliki kode sumber dari satu cabang yaitu v1 masuk ke cabang patch dan pemeliharaan untuk rilis perangkat lunak sebelumnya yaitu v2.
Ini menghasilkan waktu yang dihabiskan untuk membatalkan komit yang salah, atau salah (mungkin non-QAd) kode menjangkau dan ditempatkan di cabang yang salah jika kita tidak melihat bahwa kode tersebut telah masuk ke cabang yang salah.
Cabang dan desain / metode penggabungan kami
v1-test v1-patch1 v1-patch2
^---------^-----------^ v1-prod
/ / \ \
-----------------------/ \ \ v1-dev
\ \ \
--------------------------\ v2-dev
\ \ \
^-------^------------- v2-prod
v2-test v2-patch1
Oleh karena itu kami akan bekerja pada cabang pengembangan rilis, sampai dianggap siap , cabang itu untuk cabang pengujian / UAT / Produksi, di mana semua rilis dan pemeliharaan dilakukan. Tag digunakan untuk membuat rilis cabang ini. Saat v1 sedang diuji, cabang akan dibuat untuk v2 dan pengembang akan mulai bekerja pada fitur-fitur baru.
Apa yang cenderung terjadi adalah bahwa pengembang melakukan pekerjaan karena untuk cabang v2-dev menjadi v1-dev atau v1-prod, atau lebih buruk lagi, mereka menggabungkan v2-dev menjadi v1-prod (atau kesalahan serupa lainnya).
Kami memberi tahu sebagian besar pengembang untuk tidak mengakses cabang -prod , namun kode masih menyelinap masuk. Sekelompok pengembang yang lebih senior `menjaga 'cabang -prod.
Perlu dicatat bahwa sementara v2 baru saja memulai pengembangan, mungkin masih ada beberapa tambalan yang cukup besar ke v1 untuk memperbaiki masalah. Yaitu v1 mungkin tidak hanya mendapatkan patch kecil yang aneh.
Apa yang telah kami coba sejauh ini
- Memiliki cabang -produk yang terpisah, dengan penjaga gerbang. Cabang -prod harus memunculkan peringatan melalui namanya dan sebagian besar pengembang tidak perlu berada di cabang itu. Ini belum benar-benar mengurangi masalah.
- Meningkatkan kesadaran akan masalah ini di antara para pengembang, untuk mencoba dan membuat mereka lebih waspada. Sekali lagi ini tidak terlalu berhasil.
Kemungkinan alasan yang saya lihat untuk pengembang melakukan ke cabang yang salah
- Desain cabang terlalu rumit
- Memiliki pengembangan aktif di beberapa cabang secara paralel. (Proyek ini menunjukkan gejala menggunakan model longsor .)
- Pengembang tidak cukup memahami DVCS
Pertanyaan yang pernah saya baca yang agak relevan
Saya sudah membaca pertanyaan ini tentang tidak melakukan ke cabang yang salah dan saya merasa bahwa jawaban mengenai isyarat visual mungkin membantu. Namun saya tidak sepenuhnya yakin bahwa masalah yang kita alami bukanlah gejala dari masalah yang lebih mendasar.
Dengan petunjuk visual, kita dapat memasukkannya ke dalam baris perintah dengan mudah, namun sekitar setengah dari tim menggunakan gerhana yang saya tidak yakin bagaimana cara memasukkan isyarat visual.
Pertanyaan
Metode apa, dalam bentuk perangkat lunak, manajemen proyek atau tata kelola yang dapat kita gunakan untuk mengurangi (idealnya berhenti) melakukan komitmen ke cabang yang salah mengambil waktu kita atau mengotori kode kita yang digunakan?
Komentar spesifik tentang alasan yang saya yakin dapat berkontribusi seperti yang dijelaskan di atas akan dihargai, tetapi ini tidak seharusnya membatasi balasan Anda.