Bagaimana menyingkirkan mengembangkan cabang untuk aliran Git yang disederhanakan

Dalam proyek web yang dikembangkan secara terus-menerus (bukan produk) saat ini kami memiliki strategi percabangan berikut, secara kasar didasarkan pada aliran git :

• mengembangkan cabang: versi kerja terbaru
• cabang utama: versi yang akan dirilis / dirilis versi
• cabang fitur: fitur dalam pengembangan
• cabang hotfix: perbaikan bug mendesak dalam versi yang dirilis

Master hanya baca, diperbarui melalui permintaan tarik dari cabang berkembang atau perbaikan terbaru . Setiap pembaruan menghasilkan kandidat rilis yang sedang dibangun dan digunakan untuk sistem pementasan. Kandidat rilis disebarkan ke produksi setelah persetujuan manual.

Cabang fitur dibuat berdasarkan pengembangan , atau dari komit terakhir yang telah digabungkan menjadi master. Permintaan tarikan dari cabang fitur untuk dikembangkan dibangun, disebarkan ke sistem pengujian gratis tempat pengujian integrasi dan tes penerimaan (otomatis & manual) dijalankan. Ketika berhasil diuji dan ditinjau, PR akan digabung, sehingga akan menjadi bagian dari rilis berikutnya (yaitu menggabungkan dari pengembangan menjadi master).

Tujuanku

Saya ingin menyederhanakan ini dan menyingkirkan cabang pengembangan. Cabang pengembangan memiliki sebagian besar alasan historis dan karena selalu versi yang berhasil diuji, saya pikir tidak perlu memisahkannya dari master. Menghapusnya juga akan menyederhanakan proses rilis karena tidak ada penggabungan tambahan lagi.

Saya memiliki batasan berikut:

• rilis dijadwalkan dan tidak sepenuhnya otomatis
• sementara cabang fitur biasanya berumur pendek, beberapa tetap tidak mengalami perubahan selama beberapa minggu (misalnya desain ulang) tetapi perlu diuji juga (saat ini sebagai permintaan tarikan terbuka untuk dikembangkan)
• terkadang satu fitur harus dirilis di luar rilis reguler, secara efektif mengubahnya menjadi perbaikan terbaru. Dengan strategi saat ini saya bisa rebase cabang fitur dan menggabungkannya langsung menjadi master
• itu juga terjadi bahwa kita perlu menahan fitur setelah pengujian penerimaan dengan sistem eksternal pada staging gagal

Di mana saya tidak yakin tentang transisi:

• Saat ini saya sedang membangun permintaan tarikan untuk pengujian dan menggabungkan komitmen untuk rilis. Bisakah saya menyatukan ini?
• bagaimana menangani perbaikan terbaru saat master ada di depan rilis terbaru. Haruskah saya membuat dan menggunakan rilis langsung dari cabang hotfix?
• Adakah cara yang masuk akal untuk menangani fitur yang harus dikeluarkan dari rilis setelah mereka digabung? Apakah cabang pengembangan terpisah benar-benar menguntungkan untuk kasus ini? Sebagian besar waktu saya akhirnya mengembalikan dan kembali melakukan komitmen secara manual.

IMHO masalah yang Anda hadapi hanya efek samping dari strategi cabang miskin Anda mulai dengan: Anda secara efektif membajak pengembangan baru pada develop(yaitu apa yang konvergen menuju masa depan kode produksi) melalui yang saat ini kode produksi pada master. Ini mengarah pada persyaratan dan masalah yang bertentangan karena biasanya kode masa depan berbeda dari yang sekarang:

• perkembangan baru mengacaukan produksi - regresi terlihat setelah bergabung developke dalammaster
• menstabilkan produksi memperlambat pengembangan di masa depan - Anda perlu menstabilkan developuntuk membuatnya cukup baik untuk digabungkanmaster

Menjatuhkan developtidak akan membantu (banyak) - Anda tidak menghilangkan masalah, Anda hanya mentransfer bagian developspesifik dari masalah master.

Pendekatan yang lebih baik adalah memindahkan produksi di belakang pengembangan saat ini / masa depan, untuk mencegah gangguan dengan pengembangan untuk rilis di masa mendatang, seperti yang diilustrasikan dalam gambar ini dari What is Your Branching Model? :

Harap dicatat bahwa saya hanya merujuk ke cabang rilis pada gambar di atas, bukan pada apa yang terjadi di bagasi.

Bagaimana ini akan bekerja untuk Anda:

• yang developlenyap suatu cabang, seperti yang Anda inginkan, diserap ke dalammaster
• yang mastercabang Anda trunk, ini adalah di mana pembangunan terjadi tanpa pembatasan kecepatan (itu tidak pernah bergabung ke dalam produksi).
• produksi adalah / apakah satu atau lebih releasecabang ditarik dari masterlabel / tag yang dianggap cukup dekat dengan kualitas produksi (daftar pendek dari item todo yang tersisa dapat diatasi di cabang itu jika diperlukan). Cabang-cabang ini hanya dapat menerima hot-fix langsung dan / atau perbaikan cherry-picked dari master, mereka tidak pernah digabung dengan masteratau cabang lainnya
• perbaikan terbaru adalah komit langsung ke releasecabang

Jika perbaikan terbaru hanya berlaku untuk versi produksi tetapi tidak untuk masteritu langsung berkomitmen ke releasecabang. Jika itu berlaku untuk keduanya, maka biasanya berkomitmen untuk masterpertama dan memilih cherry / berkomitmen ganda untuk releasecabang juga.

Sekarang melihat apa yang masuk master(yang melewati titik di mana releasecabang saat ini dicabut), Anda memiliki 2 opsi:

• lanjutkan dengan fitur cabang seperti yang Anda lakukan hari ini, kecuali mereka akan didasarkan master, bukan develop. Mengubahnya ke hotfix tetap dimungkinkan - Anda hanya perlu mengubah kembali ke releasecabang yang sesuai alih-alihmaster
• beralih ke integrasi berkelanjutan dan menuai manfaatnya (dapat dilakukan kapan saja di masa mendatang), termasuk secara progresif - secara bertahap menarik lebih sedikit dan lebih sedikit cabang fitur.

Jika Anda menyukai pendekatan ini, inilah cara Anda sampai di sana dari tempat Anda berada hari ini:

• menetapkan strategi penamaan rilis:
  • Anda tidak dapat memiliki cabang rilis yang sedang berlangsung dengan nama yang sama
  • Anda tidak dapat (seharusnya tidak benar-benar) rebase atau menyinkronkan cabang rilis produksi
• tarik releaseXcabang dari mastersegera, mengikuti strategi penamaan itu
• berhenti berkomitmen untuk masuk develop, mereka akan segera menuju master.
• bergabung developmenjadimaster
• menginstruksikan pengembang untuk mengubah ruang kerja mereka masteralih-alih develop.
• terbuka masteruntuk komit
• hapus developjika Anda inginkan (atau biarkan terkunci / hanya-baca untuk referensi)

Katakanlah Anda menghapus cabang master (Anda dapat mengganti nama develop menjadi master untuk membingungkan tim Anda jika Anda suka nanti) dan cukup menggunakan tag untuk rilis baik di cabang develop atau hotfix. Anda mengambil cabang, tetapi perbedaannya hanyalah perubahan dalam sintaksis. Ubah demi perubahan.

Sekarang katakanlah Anda benar-benar mengambil pengembangan dengan menjaga cabang master yang terkunci. Apa yang akan terjadi adalah bahwa integrasi kode akan melambat, ia akan hidup lebih lama dipisahkan dalam cabang fitur, terutama yang dekat dengan tanggal rilis. Ini akan meningkatkan kesulitan penggabungan setiap kali dan memperlambat proses.

Dalam batasan yang telah Anda tentukan, saya tidak melihat efek positif dari melakukan perubahan seperti itu. Itu akan membutuhkan relaksasi kendala, terutama yang pertama.

Anda sudah membuat dan menguji kode pada setiap cabang pull-request dan hot-fix. Ini berarti bahwa secara agregat, jumlah semua cabang yang tertunda pada tarik-permintaan adalah developcabang virtual Anda .

Anda dapat membuat sistem ketika dalam lingkungan pengujian, beberapa permintaan tarik dipilih menjadi cabang sementara yang tidak dipublikasikan ke repositori utama. Cabang ini digunakan untuk mengintegrasikan lingkungan pengujian yang mencakup masterdan beberapa permintaan tarik tambahan, tetapi setelah pengujian dilakukan, cabang ini tidak lagi tersedia di mana pun.

Ketika Anda membuat rilis dari master, Anda biasanya akan membuat tag pada rilis itu. Perbaikan terbaru nanti dapat menggunakan tag itu untuk membuat cabang perbaikan terbaru baru dari mana penyebaran akan dilakukan, meskipun ujung mastersudah di depan. Di cabang perbaikan terbaru ini Anda mungkin juga akan menandai rilis kecil, dan pastikan bahwa perubahannya digabungkan master.

Menghapus fitur yang digabungkan dari rilis cukup sulit dilakukan dengan git. Mekanisme terbaik untuk ini akan digunakan git revertpada komit gabungan. Tapi itu membuat hampir tidak mungkin untuk mendapatkan fitur / perubahan ini kembali, dan sejarah menjadi kacau.

Cara yang jauh lebih baik untuk menangani pemisahan untuk penyebaran kode, dan pelepasan fitur, adalah fitur flags . Jika pengembang Anda dapat menyembunyikan fitur mereka di balik beberapa kondisi dalam kode itu sendiri, Anda dapat menggunakan kode mereka, tetapi matikan fitur tersebut. Ini adalah topik yang terpisah, tetapi banyak informasi tentang ini ada (termasuk tanya jawab tentang devops.SE).

Well @ dan-cornilescu mengatakan itu baik untuk masalah khusus Anda, tetapi kasus yang lebih umum untuk Pembangunan Berbasis Batang (disebutkan dalam Pengiriman Berkelanjutan, Lean Enterprise, dan The DevOps Handbook) dibuat di sini: https://trunkbaseddevelopment.com/