Memperkenalkan kebijakan percabangan kendali versi ke tim kecil


17

Saya seorang kontraktor yang baru-baru ini memulai dengan sebuah perusahaan.

Tim adalah 3 pengembang yang terdiri dari 2 pengembang tingkat menengah hingga menengah, dengan pengembang lainnya di tingkat yang sama segera dimulai, dan saya sendiri (6 Tahun xp). Untuk kedua pengembang yang sudah ada, ini adalah pekerjaan pertama mereka di luar universitas / perguruan tinggi, dan mereka belum pernah memiliki pengembang senior yang mengawasi pekerjaan mereka sebelumnya.

Tidak ada kebijakan kontrol Versi eksplisit. Pengembang melakukan semua pengembangan pada bagasi dan kemudian menyebar ke produksi langsung dari mesin pengembangan mereka. Tim yang ada tidak terbiasa dengan percabangan.

Saya mengubah semua ini dan memperkenalkan CI, TDD test / staging / server produksi dll, bersama dengan kebijakan kontrol versi untuk melengkapi ini.

Sistem kontrol sumber adalah TFS, yang belum pernah saya gunakan sebelumnya. Ini dikonfigurasi sebagai satu repositori raksasa.

Saya telah menuliskan beberapa petunjuk untuk mereka, tetapi apakah ada hal lain yang harus saya tambahkan / ubah, dengan mengingat pengalaman tim?

Kebijakan Kontrol Versi

Pengembangan dilakukan di bagasi

Jika perubahan diperkirakan memakan waktu lebih dari satu minggu maka itu harus dilakukan pada cabang, dengan penggabungan reguler dari batang ke cabang untuk menghentikan keduanya tidak sinkron.

Cabang rilis dibuat untuk kode produksi. Cabang itu seharusnya hanya berisi kode stabil. Kami dapat memiliki satu cabang rilis yang diperbarui dari bagasi sekali per sprint, atau kami dapat membuat cabang rilis terpisah untuk setiap minggu.

Jika perbaikan bug mendesak yang mempengaruhi kode produksi perlu dilakukan, maka akan dilakukan pada cabang rilis, dan bergabung kembali ke bagasi.

Jika kita mengadopsi strategi satu cabang rilis maka trunk akan digabung ke cabang rilis sekali per sprint menjelang akhir sprint.

Jika kami mengadopsi strategi terpisah cabang per rilis, maka trunk TIDAK PERNAH digabungkan ke dalam cabang Release

Dalam beberapa skenario mungkin perlu melakukan perbaikan bug dua kali pada cabang yang berbeda, jika cabang terlalu banyak menyimpang. Jika kita melakukan sprint pendek maka ini seharusnya tidak terlalu sering terjadi.


Saya berencana memiliki tiga server. Uji lingkungan yang selalu menjalankan kode terbaru dalam repo. Lingkungan pementasan yang menjalankan kandidat rilis terbaru untuk pementasan / pengujian kode Kandidat dan tujuan UAT, dan lingkungan produksi.

Alasan mengapa saya berencana untuk melakukan ini adalah sejauh ini klien hanya melakukan perangkat lunak internal. Proyek terbaru untuk klien media profil tinggi, dan perasaan saya adalah bahwa tim perlu mengadopsi model pengembangan yang lebih profesional daripada apa yang mereka lakukan saat ini.

Misalnya saat ini, pengguna dapat menelepon tim dengan laporan bug. Para pengembang menemukan dan memperbaiki bug, melakukan uji cepat uji bola mata pada mesin mereka sendiri dan kemudian menyebar langsung ke produksi. Tidak ada pengujian otomatis atau apa pun.


Kalau dipikir-pikir saya pikir fitur cabang adalah langkah terlalu jauh dan saya akan menghapusnya.

Jadi intinya adalah a) tidak bercabang sama sekali) b) cabang rilis dan trunk, dan c) cabang rilis per rilis dan trunk.

Saya condong ke arah yang terakhir. Pikiran awal saya adalah bahwa saya akan memiliki kandidat rilis dan rilis untuk ditayangkan di server yang terpisah (UAT / Produksi) pada saat yang sama, tetapi secara efektif trunk adalah kandidat rilis pada setiap titik waktu, jadi satu cabang per rilis condong ke arah gila. Satu-satunya pemikiran saya adalah jika kita tidak ingin para pemangku kepentingan kita melihat kode pengembangan maka kita mungkin memerlukan cabang kandidat rilis terpisah, tetapi YAGNI dan semua itu .....


3
apakah Anda mempertimbangkan untuk menambahkan penjelasan mengapa Anda memilih cara ini? katakanlah, mirip dengan bagaimana hal itu dilakukan di sini . Juga, apakah Anda memeriksa "Pedoman Percabangan Server Microsoft Team Foundation" (disebut misalnya di sini )?
nyamuk

3
Coba yang ini
gbjbaanb

1
Ingatlah bahwa saya menggunakan TFS bukan DVCS seperti GIT. Tampaknya agak spesifik git.
MrBliz

2
Akhir dari tautan itu mengatakan: "Semua orang bekerja dari trunk. Cabang ketika Anda merilis kode. Cabang dari rilis ketika Anda perlu membuat perbaikan bug untuk kode yang sudah dirilis. Cabang untuk prototipe." Saya menyarankan bahwa untuk permulaan yang sederhana, Anda hanya menandai rilis ketika Anda cukup yakin mereka Selesai. Kecuali Anda memiliki banyak pengembang yang bekerja pada banyak fitur, tidak banyak yang perlu memiliki lebih dari 1 cabang. Semua orang menambahkan fitur, semua orang memperbaiki kandidat rilis, semua orang setuju ketika sudah siap untuk menandai. Itu berarti Anda hanya perlu menyerahkan cabang untuk perbaikan bug nanti.
TafT

1
Saya tidak nyaman menempatkan ini sebagai jawaban, karena terlalu berdasarkan opini, tetapi saya telah sukses besar meyakinkan orang untuk menggunakan tag "terakhir yang dikenal baik" (LKG), yang merupakan tag bergerak di bagasi untuk mengidentifikasi yang terakhir "diberkati "versi (CCB, pengujian, dll.) Pengembang diberi tahu bahwa rilis akan dilakukan dari tag LKG ini, bukan dari kepala, dan di luar itu, mereka bebas untuk menggunakan pendekatan apa pun yang masuk akal bagi mereka pada saat itu. Saya telah menemukan pola ini untuk secara spontan menghasilkan fitur-cabang ketika waktunya tepat, tanpa upaya di muka atau kerja ekstra pada bagian pengembang.
Cort Ammon - Reinstate Monica

Jawaban:


16

Untuk tim yang terdiri dari 3-4 devs, Anda mengusulkan terlalu banyak cabang CARA.

Setiap cabang yang Anda buat adalah overhead tambahan yang disertai dengan biaya (waktu yang dihabiskan untuk menggabungkan, melacak apa yang ada di sana, dll). Anda perlu memastikan bahwa manfaat yang Anda dapatkan dari memiliki cabang lebih besar daripada biayanya.

Perlu diingat bahwa satu-satunya manfaat nyata bagi cabang adalah isolasi kode. Itu berarti Anda perlu alasan konkret untuk ingin memiliki kode yang terisolasi.

Memiliki cabang rilis terpisah untuk setiap sprint adalah gila. Mengapa Anda memerlukan kode dari satu sprint yang diisolasi dari kode untuk yang berikutnya? Mengapa tidak hanya memiliki cabang rilis stabil tunggal yang dapat dibawa maju dengan setiap sprint?

Jika perubahan diperkirakan memakan waktu lebih dari satu minggu maka itu harus dilakukan pada cabang, dengan penggabungan reguler dari batang ke cabang untuk menghentikan keduanya tidak sinkron.

Hampir semua fitur baru non-sepele akan memakan waktu setidaknya seminggu secara real-time setelah Anda memperhitungkan pengembangan, pengujian pengembang, gangguan harian dan kegiatan lainnya, dll.

Juga, apa itu "penggabungan reguler"? Harian? Mingguan? Setiap penggabungan yang Anda lakukan membutuhkan waktu - Anda perlu memastikan cabang gabungan target membangun & berjalan setelah perubahan Anda. Pada tim kecil, penggabungan yang sering adalah banyak overhead.

Kami memiliki tim yang terdiri dari 4 pengembang yang bekerja pada basis kode 1+ juta baris dan ini adalah cara kami beroperasi:

  • Cabang utama tempat semua pengembangan dilakukan
  • Satu cabang per rilis utama (dilakukan sekitar satu kali per tahun)

Satu aturan utama adalah: jangan periksa kode yang tidak dibuat.

Itu dia. Sederhana, mudah dimengerti, mendapatkan isolasi yang kita butuhkan (kapan saja kita dapat membuat versi rilis untuk versi apa pun).

Sisi baiknya untuk memiliki semua pekerjaan pengembangan dilakukan pada satu cabang:

  1. Pengembang selalu sinkron satu sama lain. Tidak ada penggabungan yang menyakitkan karena dua pengembang tidak aktif di cabang mereka sendiri selama berminggu-minggu menciptakan perubahan yang tidak kompatibel.
  2. Bangunan yang rusak ditemukan pada hari yang sama. Kami memiliki build malam yang menjalankan kode terbaru di main. Jika seseorang melakukan check-in kode yang tidak dibuat karena suatu alasan, kami akan segera tahu.
  3. Dengan setiap orang selalu bekerja pada kode yang sama, dalam meningkatkan peluang bug ditemukan lebih cepat daripada nanti.
  4. Tidak ada penggabungan overhead selain perbaikan yang ditargetkan untuk melepaskan cabang. Di tim kecil, ini yang besar.

10
"Perlu diingat bahwa satu-satunya manfaat nyata bagi cabang adalah isolasi kode. Itu berarti Anda memerlukan alasan konkret untuk ingin agar kode diisolasi." - Bagaimana dengan review kode? Saya pikir itu alasan yang bagus, bahkan dengan hanya dua devs.
BlueRaja - Danny Pflughoeft

2
Peninjauan dan percabangan kode tidak benar-benar terkait. Apakah Anda mengatakan Anda tidak ingin kode masuk ke cabang tertentu sebelum ditinjau?
17 dari 26

5
@ 17of26, ya. Tinjauan kode biasanya digunakan sebagai prasyarat untuk berada di jalur utama. Dengan demikian, Anda harus menunjukkan kode dengan cara sebelum itu: pada monitor Anda, dalam email, atau - dalam banyak pengaturan - pada cabang. Ini bekerja paling baik dengan alat manajemen repo seperti GitHub atau gerrit.
Paul Draper

3
TFS mendukung tinjauan kode melalui rak, yang merupakan area penahanan sementara dalam kendali sumber. Kode dapat tinggal di sana sampai ditinjau dan kemudian check in.
17 dari 26

2
Saya kira intinya adalah, cabang tidak benar-benar mekanisme yang digunakan untuk melakukan tinjauan kode.
17 dari 26

31

Anda telah menuliskan beberapa petunjuk untuk mereka, tetapi Anda belum menjelaskan mengapa pendekatan Anda lebih baik daripada yang sudah mereka gunakan . Ini mungkin bermasalah. Jika Anda dalam semangat "Kami akan melakukannya dengan cara saya, karena saya memiliki enam tahun pengalaman profesional, dan Anda tidak" (dan membaca pertanyaan Anda, tampaknya persis seperti ini), siap untuk dibenci oleh anggota tim Anda yang akan mencoba melakukan apa pun yang mereka tidak bisa menerapkan konsep Anda.

Apakah mereka memiliki masalah yang perlu diselesaikan? Sangat penting untuk menjawab pertanyaan ini terlebih dahulu, karena mereka benar-benar memiliki masalah dan akan menyambut saran Anda, atau mereka baik-baik saja berfungsi seperti yang mereka lakukan saat ini, dan Anda hanya mendorong mereka cara Anda bekerja , hanya karena Anda lebih suka bekerja dengan cara ini.

Akhirnya, memaksa mereka untuk menggunakan cabang dapat memiliki dampak yang sangat negatif . Bekerja dengan bagasi mudah, terutama di lingkungan Agile. Pengembang melakukan perubahan pada trunk, akhirnya menangani konflik kecil, dan perubahan tersebut segera digunakan oleh platform Integrasi Berkelanjutan. Dengan cabang:

  • Pengembang harus berpikir di mana perubahan itu harus terjadi,

  • Seseorang harus mengelola cabang dan menggabungkan dari cabang ke bagasi,

  • Penggabungan antar cabang dilakukan lebih jarang daripada melakukan, yang berarti bahwa seseorang harus berurusan dengan konflik yang lebih besar dan lebih sulit untuk ditangani daripada konflik antara dua komitmen,

  • Setiap komit tidak selalu menemukan jalannya ke Integrasi Berkelanjutan, yang menunda informasi yang didapat pengembang tentang efek komit (terutama regresi).

Fakta bahwa:

Tim yang ada tidak terbiasa dengan percabangan

membuat segalanya lebih buruk. Saya bekerja di tim programmer yang tidak berpengalaman, di mana seorang manajer yang tidak berpengalaman memutuskan untuk bermain dengan cabang. Ini menghasilkan banyak ( banyak ) waktu yang terbuang dan merupakan hal yang ingin Anda hindari untuk sebuah proyek yang memiliki tenggat waktu.


3
Nah dalam model ini, bagaimana Anda akan menghentikan kode yang tidak stabil untuk melanjutkan produksi tanpa bercabang?
MrBliz

2
@ MrBliz: melalui switch. Anda dapat mengaktifkan fitur untuk pengembang, tetapi menonaktifkannya untuk pengguna akhir jika itu tidak siap untuk RTM.
Arseni Mourzenko

3
Mengingat pengalaman para pengembang yang saya kerjakan, dan kurangnya pengujian otomatis saat ini, saya tidak berpikir itu akan menjadi ide yang bagus untuk situasi kita.
MrBliz

4
@ MrBliz Anda menghentikan kode yang tidak stabil untuk memulai produksi dengan mengisolasinya di cabang rilis (itulah tujuan mereka) dan dengan mengujinya . Cabang fitur tidak membantu dalam hal itu; pada kenyataannya ini membawa risiko yang lebih tinggi untuk memperkenalkan ketidakstabilan oleh gabungan yang besar, tidak terintegrasi, sulit dikendalikan
nyamuk

1
@ Mr Bliz ya saya perhatikan itu (dan saya pikir Anda sudah benar, jika hanya tidak menjelaskan alasan untuk mendukung itu). Hanya saja komentar Anda atau jawaban ini tidak menyebutkan secara eksplisit apakah ini tentang rilis atau cabang fitur (atau keduanya?), Jadi saya berkomentar untuk menekankan perbedaannya . FWIW menjadi kabur tentang ini mungkin satu-satunya hal yang saya tidak suka tentang jawaban ini
Agas

3

Seperti kata Mainma, berhati-hatilah dengan percabangan. Anda menyebutkan percabangan setiap beberapa minggu, apakah benar-benar perlu memiliki banyak cabang?

Atau, Anda juga bisa memiliki model 'tarik' dan bukan model dorong. Jika Anda menggunakan Git atau Mercurial, Anda bisa meminta server integrasi memvalidasi perubahan sebelum mendorong ke server pusat. Di TFS, Anda dapat melakukan hal serupa menggunakan check-in yang terjaga keamanannya . Dengan cara ini, Anda dapat memiliki validasi dan menghindari kompleksitas cabang.


Secara efektif hanya akan ada tiga cabang aktif (rilis, kandidat rilis, dan trunk) pada satu waktu, dan sebagian besar waktu hanya cabang rilis, dan trunk.
MrBliz

Cabang lama akan dihapus dalam TFS, atau lebih tepatnya disembunyikan.
MrBliz
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.