Bagaimana menyingkirkan mengembangkan cabang untuk aliran Git yang disederhanakan


20

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.

4
Tampaknya di satu sisi, Anda mengatakan Anda tidak membutuhkan cabang DEV, tetapi kemudian menjelaskan mengapa Anda benar-benar membutuhkannya. Cabang fitur yang hidup selama berminggu-minggu akan sangat sulit untuk digabungkan untuk dikuasai setelah melakukan penyelaman selama itu. Anda yakin ingin menghapus DEV?
Dave Swersky

@DaveSwersky pertanyaan bagus! Saya tidak yakin, itu sebabnya saya bertanya di sini :) Tentang cabang fitur yang berumur panjang: kesulitan untuk bergabung adalah masalah yang sudah ada dan hanya akan dipindahkan ke tempat lain. Dan dengan penggabungan reguler kembali dari cabang utama itu bisa dilakukan. Bagaimana akan lebih sulit jika cabang utama adalah master?
Fabian Schmengler

Cabang yang berumur panjang akan selalu menjadi tantangan, meskipun mungkin lebih banyak tantangan yang digabungkan untuk dikuasai daripada ke cabang DEV. Solusi untuk masalah itu adalah dengan memecah pekerjaan lebih baik agar cabang-cabang tersebut tidak berumur panjang. Jika Anda dapat mencegah cabang topik / fitur hidup lebih dari 24-48 jam, Anda mungkin lebih beruntung menghilangkan DEV.
Dave Swersky

1
@FabianSchmengler Apa alasan sebenarnya Anda ingin menghapus cabang dev? Ini benar-benar terdengar seperti Anda membutuhkannya untuk kasus-kasus ketika segala sesuatu tidak berjalan sesuai rencana.
avi

sebut itu master atau pengembangan atau apa pun yang Anda inginkan, Anda akan memerlukan cabang integrasi jika Anda ingin memiliki CI nyata, atau jika Anda mendelegasikannya ke cabang fitur, itu hanya akan menjadi integrasi luar dari mereka terhadap rilis saat ini dalam isolasi.
ᴳᵁᴵᴰᴼ

Jawaban:


6

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? :

masukkan deskripsi gambar di sini

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)

Terima kasih atas saran terperinci. Saya belum yakin apakah cabang rilis adalah ide yang bagus di luar pengembangan produk, tetapi saya akan mempertimbangkannya kembali, ini masuk akal untuk proyek ini
Fabian Schmengler

Anda juga memiliki alternatif penyebaran berkelanjutan, yang menempatkan pengembangan di tempat yang sama dengan produksi (sebagai lawan mendorong melalui atau mendahului itu), tetapi untuk itu Anda memerlukan perubahan budaya (karena itu berarti menjatuhkan semua cabang integrasi dan fitur).
Dan Cornilescu

Saya mengenali diagram itu :)
paul_h

11

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.


5

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).


2

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/

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.