Seluruh kebingungan berasal dari semantik berbeda yang digunakan MS untuk "Build number" dan terutama "Revision". Istilah itu hanya berarti hal yang berbeda.
Sebagian besar orang (termasuk saya) menggunakan skema penomoran versi semantik di mana Anda hanya mendapatkan nomor BUILD yang lebih tinggi setiap kali Anda harus membuat bangunan baru dengan alasan apa pun. Bagi kami, perbaikan terbaru dianggap hanya perubahan kode lainnya, dan bagian BUILD meningkat secara otomatis setiap kali CI dijalankan. Modul dengan MAJ.MIN.REV yang sama dianggap dapat dipertukarkan, dan BUILD memberi tahu Anda yang mana yang terbaru.
Menambah REVISION, bagaimanapun, menunjukkan cabang rilis permanen baru, itu sebabnya kami menempatkannya sebelum BUILD. Kelemahan dari pendekatan itu adalah, bahwa kita mungkin mendapatkan urutan peristiwa berikut:
- commit number 4711: Alice menambahkan fitur A
- CI menghasilkan build 1.2.3.100
- commit number 4712: Fitur yang dimodifikasi Bob B
- commit number 4713: Alice memperbaiki fitur A ("perbaikan terbaru")
- CI menghasilkan build 1.2.3.101
Seperti yang Anda lihat, perbaikan terbaru bukan satu-satunya perubahan yang ada di build berikutnya, juga modifikasi Bob menjadi bagian dari build itu. Jika Anda ingin menstabilkan cabang saat ini, Anda mungkin mengalami masalah karena Anda tidak pernah dapat memastikan apakah Bob hanya menambahkan banyak bug.
MS menggunakan kedua istilah ini secara berbeda. Nomor BUILD tidak secara otomatis bertambah, melainkan dapat dianggap sebagai jenis cabang rilis, untuk membekukan kode yang digunakan untuk versi kode tertentu. REVISION menunjukkan perubahan "panas" tambahan yang diterapkan pada cabang BUILD itu. Maka urutannya adalah sebagai berikut:
- commit number 4711: Alice menambahkan fitur A ke trunk / master
- Carl menciptakan cabang bangunan
1.2.100
- CI menghasilkan build 1.2.100.0
- commit number 4712: Bob memodifikasi fitur B di trunk / master
- commit number 4713: Alice memperbaiki fitur A di
1.2.100
cabang
- CI menghasilkan build 1.2.100.1
Istilah REVISION dapat merujuk
- sebuah produk revisi (itulah bagaimana kebanyakan orang menggunakannya)
- revisi build harian tertentu (itulah yang dilakukan MS)
Perbedaan utama antara kedua proses adalah, apakah Anda ingin atau tidak kemampuan untuk menerapkan perbaikan terbaru untuk membangun CI dan dengan demikian, pada titik mana dalam proses cabang dibuat. Aspek ini menjadi penting ketika Anda ingin dapat memilih bangunan tertentu kapan saja setelah semua tes berhasil dan mempromosikan versi itu ke rilis resmi produk Anda berikutnya.
Dalam kasus kami, alat CI membuat tag repositori, jadi kami selalu memiliki informasi yang diperlukan siap digunakan, bila diperlukan. Dengan SVN menjadi lebih sederhana, karena tag dan cabang diimplementasikan persis dengan cara yang sama - tag tidak lebih dari cabang yang berada di bawah /tags
.
Lihat juga
Dari bagian FAQ di strategi percabangan TFS :
Di cabang apa saya harus memperbaiki tiket P1 (hotfix)?
P1 harus diperbaiki di cabang yang paling dekat dengan basis kode yang berjalan di Produksi. Dalam hal ini P1 harus diperbaiki di cabang Prod. Dengan menerapkan perbaikan di cabang lain dan meluncurkan perubahan pada produksi Anda berisiko melepaskan kode setengah jadi atau belum teruji dari iterasi berikutnya.
Sekarang Anda dapat berdebat jika aman untuk bekerja secara langsung melawan cabang Prod, pikirkan lagi, P1 yang membutuhkan perhatian segera seharusnya tidak menjadi masalah mendasar dalam sistem. Dalam hal ini merupakan masalah mendasar, ia harus ditambahkan ke dalam simpanan Produk karena mungkin memerlukan analisis dan diskusi lebih lanjut dengan pelanggan.
Bacaan bagus lainnya adalah panduan percabangan TFS