Apakah Anda melanjutkan pengembangan di cabang atau di bagasi? [Tutup]

Misalkan Anda sedang mengembangkan produk perangkat lunak yang memiliki rilis berkala. Apa praktik terbaik terkait dengan percabangan dan penggabungan? Mengiris cabang rilis berkala ke publik (atau siapa pun pelanggan Anda) dan kemudian melanjutkan pengembangan pada trunk, atau mempertimbangkan trunk sebagai versi stabil, menandainya sebagai rilis secara berkala, dan melakukan pekerjaan eksperimental Anda di cabang. Apa yang dipikirkan orang-orang bahwa bagasi itu dianggap "emas" atau dianggap sebagai "kotak pasir"?

Saya sudah mencoba kedua metode dengan aplikasi komersial besar.

Jawaban untuk metode mana yang lebih baik sangat tergantung pada situasi Anda yang sebenarnya, tetapi saya akan menulis apa yang telah ditunjukkan pengalaman saya sejauh ini.

Metode yang lebih baik secara keseluruhan (menurut pengalaman saya): Batang harus selalu stabil.

Berikut adalah beberapa panduan dan manfaat dari metode ini:

• Kode setiap tugas (atau serangkaian tugas terkait) di cabang sendiri, maka Anda akan memiliki fleksibilitas kapan Anda ingin menggabungkan tugas-tugas ini dan melakukan rilis.
• QA harus dilakukan pada setiap cabang sebelum digabung ke bagasi.
• Dengan melakukan QA pada masing-masing cabang, Anda akan tahu persis apa yang menyebabkan bug lebih mudah.
• Solusi ini berskala ke sejumlah pengembang.
• Metode ini berfungsi karena percabangan adalah operasi yang hampir instan di SVN.
• Tandai setiap rilis yang Anda lakukan.
• Anda dapat mengembangkan fitur yang tidak Anda rencanakan untuk sementara waktu dan memutuskan kapan harus menggabungkannya.
• Untuk semua pekerjaan yang Anda lakukan, Anda dapat memperoleh manfaat dari melakukan kode Anda. Jika Anda bekerja hanya dari bagasi, Anda mungkin akan menyimpan banyak kode Anda tanpa komitmen, dan karenanya tidak terlindungi dan tanpa riwayat otomatis.

Jika Anda mencoba melakukan yang sebaliknya dan melakukan semua pengembangan Anda di bagasi Anda akan memiliki masalah berikut:

• Masalah build konstan untuk build harian
• Kehilangan produktivitas ketika pengembang melakukan masalah untuk semua orang lain di proyek
• Siklus rilis yang lebih lama, karena Anda akhirnya harus mendapatkan versi yang stabil
• Rilis yang kurang stabil

Anda tidak akan memiliki fleksibilitas yang Anda butuhkan jika Anda mencoba untuk menjaga cabang stabil dan bagasi sebagai kotak pasir pengembangan. Alasannya adalah bahwa Anda tidak dapat memilih dan memilih dari bagasi apa yang ingin Anda masukkan ke dalam rilis stabil. Semua sudah tercampur menjadi satu di bagasi.

Satu kasus khususnya yang akan saya katakan untuk melakukan semua pengembangan di bagasi, adalah ketika Anda memulai proyek baru. Mungkin ada kasus lain juga tergantung pada situasi Anda.

Omong-omong sistem kontrol versi terdistribusi menyediakan lebih banyak fleksibilitas dan saya sangat merekomendasikan beralih ke hg atau git.

Saya telah bekerja dengan kedua teknik dan saya akan mengatakan bahwa mengembangkan di bagasi dan bercabang poin stabil sebagai rilis adalah cara terbaik untuk pergi.

Orang-orang di atas yang keberatan mengatakan bahwa Anda akan memiliki:

• Masalah build konstan untuk build harian
• Kehilangan produktivitas ketika pengembang melakukan masalah untuk semua orang lain di proyek

mungkin belum menggunakan teknik integrasi berkelanjutan.

Memang benar bahwa jika Anda tidak melakukan beberapa tes membangun di siang hari, katakan sekali setiap jam atau lebih, akan membiarkan diri mereka terbuka untuk masalah ini yang akan dengan cepat mencekik laju perkembangan.

Melakukan beberapa tes membangun di siang hari dengan cepat melipat pembaruan ke basis kode utama sehingga orang lain dapat menggunakannya dan juga memberi tahu Anda di siang hari jika seseorang telah melanggar pembangunan sehingga mereka dapat memperbaikinya sebelum pulang.

Seperti yang ditunjukkan, hanya mencari tahu tentang bangunan yang rusak ketika bangunan malam untuk menjalankan tes regresi gagal adalah kebodohan belaka dan akan dengan cepat memperlambat segalanya.

Bacalah makalah Martin Fowler tentang Integrasi Berkelanjutan . Kami menggulirkan sistem kami sendiri untuk proyek besar (3.000 kSLOC) di sekitar 2.000 baris Posix sh.

Saya cenderung mengambil pendekatan "release branch". Batangnya mudah menguap. Setelah waktu rilis mendekati, saya akan membuat cabang rilis, yang akan saya perlakukan lebih hati-hati. Ketika itu akhirnya selesai, saya akan memberi label / memberi tag keadaan repositori sehingga saya tahu versi rilis "resmi".

Saya mengerti ada cara lain untuk melakukannya - ini hanya cara saya melakukannya di masa lalu.

Kedua.

Batangnya digunakan untuk sebagian besar pembangunan. Tetapi diharapkan upaya terbaik akan dilakukan untuk memastikan bahwa setiap check-in ke bagasi tidak akan merusaknya. (sebagian diverifikasi oleh sistem uji dan pembuatan otomatis)

Rilis dipelihara dalam direktori mereka sendiri, dengan hanya perbaikan bug yang dilakukan pada mereka (dan kemudian digabung menjadi trunk).

Setiap fitur baru yang akan meninggalkan bagasi dalam keadaan tidak stabil atau tidak berfungsi dilakukan di cabang terpisah itu sendiri dan kemudian bergabung ke dalam bagasi setelah selesai.

Saya suka dan menggunakan pendekatan yang dijelaskan oleh Henrik Kniberg di Kontrol Versi untuk Beberapa Tim Agile . Henrik melakukan pekerjaan yang hebat dalam menjelaskan bagaimana menangani kontrol versi di lingkungan yang gesit dengan banyak tim (juga bekerja untuk tim tunggal di lingkungan tradisional) dan tidak ada gunanya memparafrasekan dia jadi saya hanya akan memposting "lembar contekan" (yang dijelaskan sendiri) di bawah ini:

Saya suka itu karena:

• Sederhana: Anda bisa mendapatkannya dari gambar.
• Ia bekerja (dan berskala) dengan baik tanpa terlalu banyak masalah penggabungan dan konflik.
• Anda dapat merilis "perangkat lunak yang berfungsi" kapan saja (dengan semangat gesit).

Dan kalau-kalau itu tidak cukup eksplisit: pengembangan dilakukan di "work branch (es)", trunk digunakan untuk kode DONE (dapat dirilis). Periksa Kontrol Versi untuk Beberapa Tim Agile untuk semua detailnya.

Referensi yang baik tentang proses pengembangan yang menjaga kestabilan batang dan melakukan semua pekerjaan di cabang adalah Sistem Pengembangan Kualitas Tertinggi Divmod . Ringkasan cepat:

• Semua pekerjaan yang dilakukan harus memiliki tiket yang terkait dengannya
• Cabang baru dibuat untuk setiap tiket di mana pekerjaan untuk tiket itu dilakukan
• Perubahan dari cabang itu tidak digabungkan kembali ke bagasi utama tanpa ditinjau oleh anggota proyek lain

Mereka menggunakan SVN untuk ini, tetapi ini dapat dengan mudah dilakukan dengan sistem kontrol versi terdistribusi.

Saya pikir pendekatan kedua Anda (misalnya, menandai rilis dan melakukan hal-hal eksperimental di cabang, mengingat stabil trunk) adalah pendekatan terbaik.

Harus jelas bahwa cabang mewarisi semua bug dari suatu sistem pada titik di mana ia bercabang: jika perbaikan diterapkan ke bagasi, Anda harus pergi satu per satu ke semua cabang jika Anda mempertahankan cabang sebagai semacam terminator siklus rilis. Jika Anda sudah memiliki 20 rilis dan Anda menemukan bug yang sejauh yang pertama, Anda harus mengajukan permohonan kembali perbaikan Anda 20 kali.

Cabang seharusnya adalah kotak pasir asli, meskipun bagasi juga harus memainkan peran ini: tag akan menunjukkan apakah kode tersebut "emas" pada saat itu, cocok untuk dirilis.

Kami berkembang di bagasi kecuali perubahannya terlalu besar, tidak stabil, atau kami hampir merilis produk kami, yang dalam hal ini kami membuat cabang sementara. Kami juga membuat cabang permanen untuk setiap rilis produk individual. Saya menemukan dokumen Microsoft tentang Branching Guidance cukup membantu. Tutorial Eric Sink tentang percabangan juga menarik, dan menunjukkan bahwa apa yang berfungsi untuk Microsoft mungkin terlalu berat bagi sebagian dari kita. Dalam kasus kami, kami benar-benar menggunakan pendekatan yang Eric katakan timnya lakukan.

Itu tergantung situasi Anda. Kami menggunakan Perforce dan biasanya memiliki beberapa jalur pengembangan. Batang dianggap "emas" dan semua pengembangan terjadi pada cabang yang digabung kembali ke garis utama ketika mereka cukup stabil untuk diintegrasikan. Hal ini memungkinkan penolakan fitur yang tidak membuat pemotongan dan dapat memberikan kemampuan tambahan yang solid dari waktu ke waktu bahwa proyek / fitur independen dapat mengambil.

Ada biaya integrasi untuk menggabungkan dan mengejar fitur baru yang digulung ke bagasi, tetapi Anda tetap akan menderita rasa sakit ini. Memiliki semua orang berkembang di batang bersama-sama dapat menyebabkan situasi barat liar, sementara percabangan memungkinkan Anda untuk skala dan memilih titik di mana Anda ingin mengambil pil integrasi pahit. Kami saat ini diskalakan ke lebih dari seratus pengembang pada selusin proyek, masing-masing dengan beberapa rilis menggunakan komponen inti yang sama, dan itu bekerja dengan cukup baik.

Keindahan dari ini adalah Anda dapat melakukan ini secara rekursif: cabang fitur yang besar dapat menjadi batangnya sendiri dengan cabang lainnya terlepas jika itu. Juga, rilis final mendapatkan cabang baru untuk memberi Anda tempat untuk melakukan pemeliharaan yang stabil.

Mencoba mengelola pemeliharaan kode produksi saat ini sejalan dengan pengembangan baru merupakan masalah terbaik. Untuk mengurangi masalah-masalah tersebut, kode harus bercabang ke jalur pemeliharaan setelah upaya pengujian selesai dan kode siap untuk dikirim. Selain itu, garis utama harus bercabang untuk membantu dalam stabilisasi rilis, untuk berisi upaya pengembangan eksperimental, atau untuk menampung setiap upaya pengembangan yang siklus hidupnya meluas di beberapa rilis.

Cabang non-pemeliharaan harus dibuat hanya ketika ada kemungkinan (atau kepastian) tabrakan di antara kode yang akan sulit dikelola dengan cara lain. Jika cabang tidak memecahkan masalah logistik, itu akan membuatnya.

Pengembangan rilis normal terjadi di jalur utama. Pengembang memeriksa masuk dan keluar dari jalur utama untuk pekerjaan rilis normal. Pekerjaan pengembangan untuk tambalan ke kode Produksi saat ini harus di cabang untuk rilis itu dan kemudian digabung dengan garis utama setelah tambalan telah lulus pengujian dan digunakan. Pekerjaan di cabang non-pemeliharaan harus dikoordinasikan berdasarkan kasus per kasus.

Itu tergantung pada ukuran upaya pengembangan Anda. Beberapa tim yang bekerja secara paralel tidak akan dapat bekerja secara efektif semua pada kode yang sama (trunk). Jika Anda hanya memiliki sekelompok kecil orang yang bekerja dan perhatian utama Anda adalah memotong cabang sehingga Anda dapat terus bekerja sambil kembali ke cabang untuk membuat perbaikan bug pada kode produksi saat ini yang akan bekerja. Ini adalah penggunaan percabangan yang sepele dan tidak terlalu memberatkan.

Jika Anda memiliki banyak pengembangan paralel, Anda ingin memiliki cabang untuk setiap upaya tetapi itu juga akan membutuhkan lebih banyak disiplin: Pastikan cabang Anda diuji dan siap untuk bergabung kembali. Menjadwalkan penggabungan sehingga dua kelompok tidak mencoba untuk bergabung pada saat yang sama dll.

Beberapa cabang sedang dalam pengembangan begitu lama sehingga Anda harus mengizinkan penggabungan dari batang ke cabang untuk mengurangi jumlah kejutan ketika akhirnya bergabung kembali ke bagasi.

Anda harus bereksperimen jika memiliki sekelompok besar pengembang dan merasakan apa yang berhasil dalam situasi Anda. Berikut adalah halaman dari Microsoft yang mungkin agak berguna: http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

Kami menggunakan trunk untuk pengembangan utama dan cabang untuk pekerjaan pemeliharaan rilis. Ini bekerja dengan baik. Tapi kemudian cabang seharusnya hanya digunakan untuk perbaikan bug, tidak ada perubahan besar, terutama di sisi basis data, kami memiliki aturan bahwa hanya perubahan skema yang bisa terjadi di trunk utama dan tidak pernah di cabang.

Jika Anda akan bekerja melalui siklus rilis, fitur besar, Anda terdampar ke cabang. Kalau tidak, kami bekerja di bagasi, dan cabang untuk setiap rilis produksi pada saat kami membangun.

Pembuatan produksi sebelumnya dipindahkan pada waktu itu ke old_production_ dan rilis prod saat ini selalu hanya produksi. Semua server build kami tahu tentang produksi adalah cara menggunakan cabang produksi, dan kami menendang yang membangun dengan pemicu kekuatan.

Kami mengikuti trunk = aliran pengembangan saat ini, cabang = rilis (s) pendekatan. Pada rilis ke pelanggan kami cabang bagasi dan hanya terus bergulir ke depan. Anda harus membuat keputusan tentang berapa banyak rilis yang siap Anda dukung. Semakin Anda mendukung semakin banyak penggabungan yang akan Anda lakukan pada perbaikan bug. Kami mencoba dan mempertahankan pelanggan kami tidak lebih dari 2 rilis di belakang bagasi. (Misalnya. Dev = 1.3, rilis yang didukung 1.2 dan 1.1).

Bagasi umumnya merupakan jalur pengembangan utama.

Rilis bercabang dan sering kali pekerjaan eksperimental atau besar dilakukan pada cabang kemudian digabungkan kembali ke bagasi ketika sudah siap untuk diintegrasikan dengan jalur pengembangan utama.

Batang umumnya harus menjadi sumber pengembangan utama Anda. Kalau tidak, Anda akan menghabiskan banyak waktu untuk menggabungkan fitur-fitur baru. Saya telah melihatnya dilakukan dengan cara lain dan biasanya menyebabkan banyak sakit kepala integrasi menit terakhir.

Kami memberi label rilis kami sehingga kami dapat dengan cepat menanggapi keadaan darurat produksi tanpa mengganggu pengembangan aktif.

Bagi saya, itu tergantung pada perangkat lunak yang saya gunakan.

Di bawah CVS, saya hanya akan bekerja di "trunk" dan tidak pernah menandai / cabang, karena itu sangat menyakitkan untuk melakukan sebaliknya.

Dalam SVN, saya akan melakukan "edge edge" saya di trunk, tetapi ketika tiba saatnya server push ditandai dengan tepat.

Saya baru saja beralih ke git. Sekarang saya menemukan bahwa saya tidak pernah bekerja di bagasi. Alih-alih, saya menggunakan cabang sandbox bernama "new-featureename" dan kemudian bergabung menjadi cabang "produksi-saat ini" yang sudah diperbaiki. Sekarang saya berpikir tentang hal itu, saya benar-benar harus membuat cabang "release-VERSIONNUMBER" sebelum bergabung kembali ke "produksi saat ini" sehingga saya dapat kembali ke versi stabil yang lebih lama ...

Itu benar-benar tergantung pada seberapa baik organisasi / tim Anda mengelola versi dan SCM yang Anda gunakan.

• Jika apa yang berikutnya (dalam rilis berikutnya) dapat dengan mudah direncanakan, Anda lebih baik berkembang di bagasi. Mengelola cabang membutuhkan lebih banyak waktu dan sumber daya. Tetapi jika selanjutnya tidak dapat direncanakan dengan mudah (terjadi sepanjang waktu di organisasi yang lebih besar), Anda mungkin akan berakhir dengan komitmen memetik ceri (ratusan / ribuan) daripada cabang (beberapa atau puluhan).
• Dengan Git atau Mercurial, mengelola cabang jauh lebih mudah daripada cvs dan subversi. Saya akan menggunakan metodologi cabang trunk / topik yang stabil. Inilah yang digunakan oleh tim git.git. baca: http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
• Dengan Subversion, saya pertama kali menerapkan metodologi develop-in-the trunk. Ada beberapa pekerjaan ketika datang ke tanggal rilis karena setiap kali saya harus memilih komitmen (perusahaan saya tidak pandai perencanaan). Sekarang saya semacam ahli dalam Subversion dan tahu cukup baik tentang cabang manaing di Subversion, jadi saya bergerak menuju metodologi trunk / topik cabang stabil. Ini bekerja jauh lebih baik daripada sebelumnya. Sekarang saya mencoba cara kerja tim git.git, meskipun kami mungkin akan tetap menggunakan Subversion.

Berikut adalah desain SVN yang saya sukai:

• akar
  • pengembangan
    • ranting
      • fitur1
      • fitur2
      • ...
    • bagasi
  • beta
    • tag
    • bagasi
  • melepaskan
    • tag
    • bagasi

Semua pekerjaan dilakukan dari pengembangan / trunk, kecuali untuk fitur-fitur utama yang memerlukan cabangnya sendiri. Setelah pekerjaan diuji terhadap pengembangan / trunk, kami menggabungkan masalah yang diuji ke dalam beta / trunk. Jika perlu, kode diuji terhadap server beta. Saat kami siap meluncurkan beberapa perubahan, kami hanya menggabungkan revisi yang sesuai menjadi rilis / trunk dan penyebaran.

Tag dapat dibuat di cabang beta atau cabang rilis sehingga kami dapat melacak rilis spesifik untuk beta dan rilis.

Desain ini memungkinkan banyak fleksibilitas. Ini juga memudahkan kita untuk meninggalkan revisi dalam versi beta / trunk sementara menggabungkan yang lain untuk rilis / trunk jika beberapa revisi tidak lulus tes dalam versi beta.

Metode yang kami gunakan adalah pendekatan Perforce, yang dibahas panjang lebar dalam buku hebat Laura Wingerd:

http://oreilly.com/catalog/9780596101855/index.html

Meskipun buku ini adalah perforce centric (Wingerd adalah manajer produk Perforce), konsep-konsepnya dapat diterapkan pada sebagian atau semua VCS.

Pendekatan perforce (dan platform) telah membantu kami dengan sangat baik. Ini digunakan di banyak perusahaan (google, Intuit, dan, saya dengar, Microsoft Windows itu sendiri).

Buku ini layak dibaca.

Baca ini: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Tidak ada jawaban satu ukuran untuk semua untuk pertanyaan konvensi subversi IMHO.

Itu benar-benar tergantung pada dinamika proyek dan perusahaan yang menggunakannya. Dalam lingkungan yang serba cepat, ketika rilis mungkin terjadi sesering setiap beberapa hari, jika Anda mencoba menandai dan bercabang secara religius, Anda akan berakhir dengan repositori yang tidak dapat dikelola. Dalam lingkungan seperti itu, pendekatan cabang saat dibutuhkan akan menciptakan lingkungan yang jauh lebih dapat dipertahankan.

Juga - dalam pengalaman saya, sangat mudah, dari sudut pandang administrasi murni, untuk beralih di antara metodologi svn ketika Anda mau.

Dua pendekatan yang saya tahu paling berhasil adalah cabang-saat-dibutuhkan, dan cabang-masing-masing tugas. Ini, tentu saja, semacam kebalikan dari satu sama lain. Seperti yang saya katakan - ini semua tentang dinamika proyek.

@Brian R. Bondy: Harap dicatat bahwa ini bukan solusi setelah tim Anda mencapai sejumlah tugas / tugas yang ditangani secara paralel pada proyek.

Setelah departemen QA terlibat dalam qa, upaya yang diperlukan untuk menyediakan satu instalasi per cabang yang sedang berjalan terlalu tinggi. Pikirkan SOA / Klien / Server / WebServices / Database yang semuanya harus disediakan per cabang .

Solusi ini juga tidak memiliki tahap integrasi.