Memiliki cabang produksi atau menggunakan master?


16

Saya bekerja pada tim kecil dengan pengembang jarak jauh lainnya pada suatu Railsaplikasi. Kami mulai mengubah gitalur kerja kami . Kami telah memikirkan tentang struktur percabangan seperti di bawah ini:

(dev) -> (qa) -> (stag) -> (master)

Tetapi beberapa pengembang berpikir itu mungkin kurang membingungkan bagi pengembang baru yang mungkin secara otomatis mendorong produksi pada master. Sebagai gantinya mereka mengira semua orang bekerja sebagai master dan membuat cabang terpisah untuk produksi.

(master) -> (qa) -> (stag) -> (prod)

Saya diajari bahwa Anda ingin agar master tetap dapat digunakan dan tidak menggunakannya sebagai pengembangan dan dari tempat sebelumnya saya pernah bekerja, master selalu dimaksudkan untuk dapat digunakan untuk produksi.

Apa yang akan menjadi kelemahan menggunakan struktur percabangan di mana master secara aktif digunakan untuk pengembangan dan cabang prod terpisah adalah apa yang Anda gunakan untuk penyebaran?

git 

Dalam pengalaman saya, itu bermanfaat untuk memiliki satu tempat di mana orang dapat berkomitmen untuk sesuka hati (baik itu untuk check-in harian atau apa pun) - tanpa persyaratan untuk "selalu dikompilasi". Tanpa itu orang menunda check-in dan berisiko kehilangan kode dalam kecelakaan (mis. Kecelakaan disk). Kemudian, terserah mereka untuk menyebarkan versi yang bermakna dari sana dan "lepaskan" ke arah aliran integrasi. Jadi set panggung pilihan saya adalah seperti (dev) -> (unit) -> (integrasi) -> (tes) -> (produksi)
BitTickler

2
Kami berhasil menggunakan alur kerja git yang dijelaskan di situs ini dengan beberapa perbedaan. nvie.com/posts/a-successful-git-branching-model Satu-satunya perbedaan adalah bahwa kami lebih suka cabang lokal masuk ke dalam mengembangkan satu untuk mempertahankan histori bersih dan mengikuti logika "satu komitmen, satu masalah"
Jepessen

Apa yang biasanya terjadi pada cabang "rusa jantan" Anda?
Simgineer

merekomendasikan untuk CI / CD yang lebih jelas. cabang master tidak digunakan karena mungkin disalahtafsirkan. {mengembangkan} - {unit} - {integrasi} - {pementasan} - {produksi}. berwarna biru / hijau memiliki produksi terus menerus membangun> irisan aktif, dan staging> irisan tidak aktif. KEPALA> mengembangkan cabang tempat fitur bercabang. mengembangkan memiliki webhook untuk memicu pengembangan menuju unit yang maju ke integrasi dan pementasan (dengan tag yang sesuai saat melewati integrasi). perbaikan terbaru menuju pengembangan + produksi (jarang tetapi itu terjadi). lebih banyak seluk beluk tetapi gagasan umum.
Jimmy MG Lim

Jawaban:


16

Tidak ada kelebihan atau kekurangan untuk pendekatan ini. Alasan saya mengatakan ini sederhana: bagi Git, tidak ada bedanya jika Anda mengembangkan dari master atau melepaskan dari master. Anda bahkan tidak perlu melepaskan cabang; Anda bisa menandai komit sewenang-wenang dan melepaskannya, sebagai gantinya.

Masalah sebenarnya di sini adalah salah satu proses dan prosedur. Para pengembang yang lebih senior yang khawatir bahwa melakukannya dengan satu cara akan membingungkan para pengembang yang lebih baru perlu dipersiapkan untuk menginvestasikan waktu untuk menjelaskan apa model rilis dan mengapa demikian.

Selama semua orang memahami bahwa master adalah untuk pengembangan, dan beberapa cabang sewenang-wenang lainnya adalah untuk rilis, dan pekerjaan untuk mempertahankan ini dilakukan , maka seharusnya tidak ada masalah dengan pendekatan ini.


1
Saya benar-benar berpikir bahwa Anda mencapai titik yang baik. Terima kasih untuk umpan baliknya.

+1 untuk komitmen pemberian tag. Saya bekerja sendiri hampir sepanjang waktu, tetapi saya memberi tag rilis karena dua alasan. 1) Ini bekerja sangat baik dengan alat sejarah visual git untuk menunjukkan komit yang sebenarnya telah diproduksi. 2) Ini bekerja sangat baik dengan alat-alat seperti GitHub yang dapat mengemas versi rilis dengan memeriksa komit yang ditandai dan mengemasnya ke dalam file zip untuk dikonsumsi.
nbering

9

Saya bisa melihat dilema Anda. Saya juga memilikinya, sampai saya tidak mempelajari apa yang selalu saya asumsikan tentang tuan.

Saya diajari bahwa Anda ingin agar master tetap dapat digunakan dan tidak menggunakannya sebagai pengembangan dan dari tempat sebelumnya saya pernah bekerja, master selalu dimaksudkan untuk dapat digunakan untuk produksi.

Dari dokumentasi / buku Git - Cabang Git

Cabang "master" di Git bukan cabang khusus. Persis seperti cabang lainnya. Satu-satunya alasan hampir setiap repositori memilikinya adalah karena perintah git init membuatnya secara default dan kebanyakan orang tidak repot-repot mengubahnya.

Jadi, jika Anda memiliki alur kerja yang disukai, dan sulit untuk bekerja dengannya karena pengembang yang berbeda di tim memiliki ide yang berbeda master. Anda bahkan dapat mempertimbangkan masteruntuk mengganti nama untuk mengatakan proddan menggunakan alur kerja seperti di bawah ini -

(dev) -> (qa) -> (stag) -> (prod)

Inilah cara Anda mengubah nama cabang master .

Saya TIDAK mengatakan bahwa Anda harus mengubah masternama cabang. Tetapi jika Anda memiliki alur kerja yang disukai dan itu membantu untuk mengubah masternama cabang, lakukan dengan segala cara :-)


Itu poin yang sangat bagus. Terima kasih telah menyiapkannya. Saya tidak tahu apakah kita akan mengubah nama itu terlalu jauh tetapi ada baiknya mengetahui bahwa git tidak memperlakukan master dengan cara khusus. Terima kasih!

6

Saya lebih suka cek daripada konvensi dalam hal ini. Setiap tim berisi anggota yang lebih baik dalam memulai fitur baru dan orang lain yang lebih baik dalam menstabilkan hal-hal untuk rilis.

Jika Anda kekurangan yang terakhir, maka ulasan kode akan membantu (seringkali, orang yang lebih disiplin akan menginginkan ulasan kode).

Itulah mengapa kami mengonfigurasi repo Git kami (kami menggunakan Gitlab) yang hanya orang tertentu yang dapat menggabungkan permintaan tarik dan setiap pengembang mendapatkan garpu pribadi dari repo utama.

Itu memecahkan dua masalah:

  1. Pengembang baru tidak dapat mengubah cabang yang salah (karena mereka tidak dapat mendorong pekerjaan mereka langsung ke repo utama). Mereka mungkin mendorong untuk masterrepo mereka sendiri tetapi itu akan diperbaiki ketika permintaan tarik masuk.

  2. Konvensi kode cepat menyebar ke seluruh tim karena setiap komit diperiksa oleh setidaknya orang lain yang membawa pandangan dan pengetahuan mereka.


1

Itu semua tergantung pada proses pengembangan perangkat lunak secara keseluruhan. Manajemen konfigurasi dan bagaimana versi baru muncul tidak dapat didefinisikan tanpa mengetahui tentang keseluruhan proses.

Ada fraksi "gesit" yang akan memilih untuk "area komit pertama yang selalu berfungsi". Mereka akan menjalankan pembangunan otomatis dan menguji fasilitas secara konstan terhadap area itu dan mencoba untuk memiliki sistem kerja "setiap saat".

Mereka akan melihat (master) -> (rilis) dengan mungkin 1,2 langkah menengah organisasi bermanfaat.

Kemudian ada fraksi yang lebih "klasik", yang memiliki proses yang didorong oleh perencanaan dan langkah-langkah integrasi yang terencana menuju tonggak, di mana rilis "unit kerja" adalah kegiatan yang direncanakan dengan persyaratan seperti "hanya rilis ketika diuji (unit) dan seharusnya cocok dengan tonggak yang direncanakan berikutnya ". Di sana, perencanaan terdiri dari versi "unit kerja" dan biasanya mereka berusaha keras untuk menentukan bagaimana rilis produk yang direncanakan berikutnya akan terlihat seperti dalam hal fitur dan perbaikan. Demi perencanaan, mereka ingin tahu bahwa apa yang dikeluarkan pengembang adalah "tepat" dan tindakan sadar untuk melakukan unit kerja.

Pendekatan klasik itu tidak berarti bahwa ada waktu yang lebih lama di mana tidak ada produk lengkap yang tersedia.

Jadi alur kerja "klasik" adalah: (dev) -> (unit) -> (integrasi) -> (test / qa) -> (produksi).

Peran integrator adalah untuk "menerima / membeli" unit yang dirilis atau menolaknya jika tidak sesuai dengan kebutuhan rilis mendatang yang akan datang.

Selain itu, dimungkinkan juga untuk mencampur kedua pendekatan dasar tersebut dengan cara yang tepat.

Dari pengalaman saya (yang sebagian besar di bidang menggunakan pendekatan "klasik"), pendekatan "klasik" bekerja dengan baik dalam proyek-proyek dari sekitar 4-50 orang dalam satu tim.

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.