Kami adalah perusahaan kecil dengan banyak tim yang mengelola repositori git mereka sendiri. Ini adalah platform web dan artefak masing-masing tim dikerahkan pada akhir hari untuk tes malam hari. Kami mencoba memformalkan proses seputar versi dan pengemasan.
Setiap tim memiliki cabang utama di mana mereka melakukan pengembangan sehari-hari. Anggota jaminan kualitas dari setiap tim menginginkan artefak dari perubahan tim mereka dikerahkan ke test bed di mana semua komponen digabungkan oleh chef. Artefak adalah tarbal tetapi saya ingin mengubahnya menjadi RPM sehingga kami dapat berpikir dan berargumen tentang versi dengan benar.
Proses rilis melibatkan pemotongan cabang rilis dari cabang pengembangan (master dalam kebanyakan kasus) dari masing-masing repositori git. Ini kemudian diberikan kepada jaminan kualitas yang menjalankan tes dan sign-off pada serangkaian artefak.
Untuk mis. Ini adalah repositori git yang khas dengan cabang rilis yang terkait:
0-0-0-0-0-0-0-0-0-0 (master)
| |
0 0
(rel-1) |
0
(rel-2)
Saya terjebak mencoba mencari skema untuk melakukan versi paket yang berasal dari cabang pengembangan. Kami tidak ingin memberi tag berlebihan pada cabang master dari setiap repo dan membatasi tag untuk melepaskan cabang saja. Tetapi kita harus dapat menanyakan paket yang ditempatkan di mesin uji menggunakan semantik yum / rpm standar. Seperti apakah versi pengembangan ketika cabang master tidak memiliki tag? Saya mengerti bahwa ini git describebisa memberi saya representasi yang berguna dari versi build tetapi itu bekerja dengan baik ketika berbagai titik rilis di cabang ditandai.
EDIT1: Menanggapi jawaban @ Urban48
Saya pikir saya harus menjelaskan proses rilis kami sedikit lagi. Untuk keperluan diskusi ini, mari kita asumsikan kita memiliki cabang masterdi semua repositori. The mastercabang dianggap cabang pengembangan dan dikerahkan ke otomatis CI-CD diaktifkan lingkungan QA. Di sinilah sebagian tes malam berjalan untuk memastikan stabilitas master. Kami melihat pipa pekerjaan ini sebelum memotong cabang rilis. Cabang pembebasan kami berumur pendek. Katakanlah, setelah memotong cabang rilis (dari master stabil), regresi penuh dijalankan, perbaikan dilakukan dan digunakan untuk produksi. Ini membutuhkan waktu sekitar satu minggu untuk dilakukan. Kami merilis hampir setiap dua minggu untuk produksi.
Cabang fitur kami selalu dipotong dari master dan menjalani sejumlah pengujian pengembang sebelum bergabung dengan master yang di atasnya mereka menjalani pemeriksaan stabilitas CI-CD.
Perbaikan terbaru dibuat pada cabang perbaikan terbaru (dipotong dari cabang rilis) dan digunakan dengan pengujian dampak minimal ke dalam produksi.
Strategi versi kami untuk rilis dan cabang perbaikan terbaru mengikuti semver. Rilis cabang selama siklus QA melalui versi seperti v2.0.0-rc1, v2.0.0-rc2dan akhirnya setelah QA sign-off menjadi v2.0.0.
Kami terkadang melakukan rilis bertitik untuk fitur kecil yang digabungkan untuk melepaskan cabang (dan kemudian dikuasai) di mana versi menjadi v2.1.0. Dan perbaikan terbaru mengasumsikan v2.1.1polanya.
Namun pertanyaannya, bukan tentang membuat versi cabang-cabang ini. Saya lebih suka untuk tidak mengubah skema versi ini sama sekali. Satu-satunya perubahan muncul untuk cabang pengembangan yaitu. menguasai. Bagaimana saya bisa menunjukkan dengan andal di lingkungan CI-CD versi mana yang ada saat rilis sebelumnya ke produksi. Ini idealnya akan dilakukan melalui penandaan smart git tetapi sesuatu yang tidak berlebihan menandai cabang master lebih disukai.
rcsufiks? Itu akan menentukan major.minorversi pengembangan. rcdan nomor build hanya bisa didapat berdasarkan itu. Juga rcpada master tidak masuk akal karena kita tidak pernah melepaskan dari master. Kami menandai kandidat rilis kami hari ini di cabang rilis sebagai bagian dari siklus rilis
rcakhiran.
