Haruskah Anda repot dengan cabang SVN jika Anda hanya pernah memilikinya?

Jika kita hanya bekerja dengan satu cabang di Subversion, haruskah kita repot-repot? Tidak bisakah kita bekerja di bagasi untuk mempercepat?

Inilah cara kami berkembang dengan Subversion:

Ada belalai
Kami membuat cabang pengembangan baru
Kami mengembangkan fitur baru di cabang itu
Ketika fitur selesai, itu digabung dalam bagasi, cabang dihapus dan cabang pengembangan baru dibuat dari bagasi

Ketika kami ingin merilis untuk produksi, kami membuat tag dari bagasi. Perbaikan bug dilakukan pada cabang dari tag itu. Perbaikan bug ini kemudian digabungkan dalam bagasi.

Inilah sebabnya kami membuat cabang pengembangan baru setelah fitur selesai. Dengan cara ini, perbaikan bug segera dimasukkan dalam kode baru kami.

Di bawah ini adalah diagram yang harus menjelaskan:

Strategi Subversi kami

Sekarang, ada perasaan bahwa ini bukan cara kerja yang paling efisien. Kami membangun secara lokal sebelum berkomitmen, yang membutuhkan waktu sekitar 5-10 menit. Anda dapat memahami bahwa ini dialami sebagai waktu tunggu yang cukup lama.

Gagasan cabang pengembangan adalah bahwa trunk selalu siap-lepas. Tapi ini tidak benar dalam situasi kita lagi. Kadang-kadang, sebuah fitur hampir siap, dan beberapa pengembang sudah mulai mengkodekan fitur berikutnya (jika tidak, mereka akan duduk menunggu satu atau dua pengembang untuk menyelesaikan dan menggabungkan).

Kemudian, ketika fitur 1 selesai, ia digabungkan ke dalam bagasi, tetapi dengan beberapa komitmen fitur 2 disertakan.

Jadi, haruskah kita repot-repot dengan cabang pengembangan, karena kita hanya punya satu cabang? Saya telah membaca tentang pengembangan berbasis trunk dan abstraksi cabang, tetapi sebagian besar artikel yang saya temukan fokus pada bagian abstraksi cabang. Saya mendapatkan kesan bahwa itu untuk perubahan besar yang akan berlangsung selama beberapa rilis. Ini bukan masalah yang kita alami.

Bagaimana menurut anda? Bisakah kita bekerja di bagasi? Skenario terburuk adalah (saya pikir) bahwa kita harus membuat tag dari bagasi dan memilih-ceri komit yang kita butuhkan, karena beberapa komit / fitur belum siap produksi.

svn branching tagging

— Peter
sumber

Saya pikir akan lebih baik jika Anda memiliki lebih dari satu cabang. Satu untuk setiap fitur. Dengan cara ini, jika Anda pernah mulai bekerja pada fitur besar yang akan memakan waktu, Anda tidak akan menahan perbaikan bug dan semacamnya untuk versi yang sudah dirilis.

— Amy Anuszewski

Cabang untuk setiap fitur tampaknya membuatnya lebih rumit, sementara kami mencoba mengurangi kompleksitas. Juga, jika ada perbaikan bug (yaitu untuk 1.0), itu bisa dilakukan pada cabang yang dibuat dari tag. Kemudian kita dapat menandai cabang itu (membuat 1.1), melepaskannya, dan menggabungkan perbaikan bug ke dalam trunk. Pengembangan fitur besar akan berlanjut di bagasi.

— Peter

Jawaban:

IMHO bekerja langsung pada trunk baik-baik saja jika Anda dapat melakukan sedikit demi sedikit dan Anda memiliki integrasi berkesinambungan di tempat, sehingga Anda dapat memastikan (sampai batas tertentu) bahwa komitmen Anda tidak merusak fungsi yang ada. Kami melakukannya juga di proyek kami saat ini (pada kenyataannya saya belum bekerja di proyek apa pun menggunakan cabang spesifik tugas secara default).

Kami hanya membuat cabang sebelum rilis, atau jika fitur membutuhkan waktu lama untuk diimplementasikan (yaitu merentang beberapa iterasi / rilis). Ukuran tugas yang kasar hampir selalu dapat diperkirakan dengan cukup baik sehingga kita tahu sebelumnya apakah kita membutuhkan cabang yang terpisah untuk itu. Kami juga tahu berapa banyak waktu yang tersisa sebelum rilis berikutnya (kami menerbitkan rilis kira-kira setiap 2 bulan) sehingga mudah untuk melihat apakah suatu tugas cocok dengan waktu yang tersedia sebelum rilis berikutnya. Jika ragu, kami menundanya sampai cabang rilis dibuat, maka tidak apa-apa untuk mulai mengerjakannya di bagasi. Sejauh ini kami hanya perlu membuat cabang khusus tugas sekali (sekitar 3 tahun). Tentu saja proyek Anda mungkin berbeda.

— Péter Török
sumber

Saya dengan Peter. Kami memiliki cabang untuk setiap rilis yang didukung, tetapi jika tidak berfungsi di bagasi. Kami juga menggunakan integrasi Berkelanjutan, tetapi perlu diketahui bahwa ini hanya berarti akan dikompilasi dan tidak merusak fungsionalitas yang ada, bahkan dengan pengujian unit.

— Ian

@Ian, tentu saja tidak ada tes yang dapat memastikan dalam kehidupan nyata bahwa kode tersebut 100% bebas bug ... memiliki sumber daya yang terbatas, kami bertujuan untuk tingkat keamanan yang wajar (definisi yang khusus untuk domain dan proyek). Perhatikan juga bahwa CI dapat menjalankan tes integrasi dll juga, tidak hanya tes unit.

— Péter Török

Ini berfungsi sampai gagal. Jika Anda perlu menerapkan perbaikan sebelum fitur baru siap ... Atau jika rilis fitur baru tidak siap untuk primetime seperti yang Anda pikir akan jauh lebih sulit untuk mendukung perubahan yang keluar dari kode jika Anda tidak menggunakan percabangan.

— SoylentGray

@ Chad, patch ke rilis terbaru dilakukan pada cabang rilis yang sesuai, tanpa gangguan dari trunk. Dan kami menguji fitur-fitur baru dengan cukup luas sehingga kami tahu kapan mereka siap untuk prime time. Memang, kami memiliki sedikit fitur besar dalam proyek kami. Dan karena ini adalah aplikasi web sisi server, cukup mudah bahkan untuk menambahkan tanda DB untuk mengaktifkan / menonaktifkan fitur secara selektif. YMMV.

— Péter Török

LOL ok Saya salah mengerti dan mengira Anda baru saja memiliki trunk (dengan satu pengecualian) Saya telah menggunakan metode ini juga baik untuk grup kecil dan sering rilis kecil itu tidak berfungsi dengan baik bagi kami melakukan rilis besar secara teratur (3-6 bulan) ) intevals.

— SoylentGray

Apa yang Anda gambarkan dengan pengembangan fitur Anda adalah pengembangan paralel (pengembangan simultan menargetkan rilis produk yang berbeda) dan memang memerlukan cabang untuk menanganinya dengan benar. Anda bisa memiliki satu cabang baik untuk setiap rilis atau untuk setiap fitur jika Anda sering harus mengomposisi ulang fitur yang akan membuat rilis tertentu.

Cara lain untuk melakukan ini, adalah dengan bekerja di luar dari trunk secara default tetapi membuat cabang jika Anda mengharapkan tugas Anda untuk melampaui melewati rilis berikutnya. Anda selalu menandai rilisnya saja.

Pendekatan mana yang Anda lakukan benar-benar tergantung pada seberapa banyak manajemen yang dapat Anda lakukan di muka. Jika rilis khas tidak benar-benar memiliki pengembangan paralel maka saya akan mengambil pendekatan kedua.

— Jeremy
sumber

Saya setuju dan OP mengonfirmasi hal ini dengan: 'Kadang-kadang, sebuah fitur hampir siap, dan beberapa pengembang sudah akan mulai mengkodekan fitur berikutnya ...'

— Chris

Ya, tapi kami tidak pernah harus menyusun ulang. Fitur diimplementasikan secara kronologis dan, misalnya, fitur 1-4 semuanya harus ada di rilis berikutnya (katakanlah 1.0). Satu-satunya saat ini bisa menjadi masalah adalah ketika pengembangan telah dimulai pada fitur 5, yang untuk rilis setelah itu (2.0). Maka kita harus memastikan bahwa perubahan ini tidak dilakukan dalam tag / rilis (1.0). Membuat cabang sebelum rilis memang bisa memperbaikinya.

— Peter