Praktik / panduan terbaik untuk mempertahankan nomor versi perakitan

Saya mencari petunjuk, saran, dan bahkan dikte tentang cara mengelola tiga nomor versi rakitan berbeda untuk rakitan .NET. Versi Produk adalah yang paling sederhana, karena tampaknya ini biasanya ditentukan oleh bisnis. Kemudian, versi file tampaknya untuk versi antar penyebaran, di mana versi perakitan sebenarnya hanya digunakan saat pengiriman.

Saat ini saya hanya mencari cara sederhana untuk memberi label uji dan pemeliharaan rilis dari sebuah rakitan yang tidak bergantung, jadi saya melihat angka penambahan dan revisi peningkatan otomatis pada versi file, dan untuk rilis final, menyalin saat ini versi file ke versi assembly. Produk ini dalam penggunaan produksi, tetapi masih dalam pengembangan - Anda tahu - salah satu dari perusahaan kecil itu, tidak ada perubahan situasi infrastruktur kontrol.

Versi adalah sesuatu yang saya sangat sukai dan telah menghabiskan waktu lama mencoba untuk datang dengan sistem versi yang mudah digunakan. Dari apa yang telah Anda katakan dalam pertanyaan Anda, jelas bahwa Anda telah memahami satu poin penting, nomor versi perakitan tidak sama dengan versi produk. Yang satu digerakkan secara teknis, dan yang lain digerakkan oleh bisnis.

Berikut ini mengasumsikan bahwa Anda menggunakan beberapa bentuk kontrol sumber dan server build. Untuk konteks kami menggunakan TeamCity dan Subversion / Git. TeamCity gratis untuk sejumlah kecil (10) proyek dan membangun server yang sangat baik tetapi ada yang lain, beberapa di antaranya benar-benar gratis.

Apa arti nomor versi

Apa arti suatu versi bagi satu orang dapat berarti sesuatu yang berbeda dari yang lain, struktur umumnya adalah utama, minor, makro, mikro. Cara saya melihat nomor versi adalah memecahnya menjadi dua bagian. Babak pertama menjelaskan versi utama (Mayor) dan setiap pembaruan utama (Minor). Babak kedua menunjukkan kapan itu dibangun dan apa versi kode sumber itu. Nomor versi juga memiliki arti berbeda tergantung pada konteksnya, apakah itu API, Aplikasi Web, dll.

Major. Minor. Build.Revision

• Revision Ini adalah angka yang diambil dari kontrol sumber untuk mengidentifikasi apa yang sebenarnya dibangun.
• BuildIni adalah angka yang terus meningkat yang dapat digunakan untuk menemukan build tertentu di server build. Ini adalah angka penting karena server build mungkin telah membangun sumber yang sama dua kali dengan serangkaian parameter yang berbeda. Menggunakan nomor build bersama dengan nomor sumber memungkinkan Anda untuk mengidentifikasi apa yang dibangun dan bagaimana.
• MinorIni hanya akan berubah ketika ada perubahan signifikan ke antarmuka publik. Misalnya, jika itu adalah API, apakah kode yang dikonsumsi masih dapat dikompilasi? Nomor ini harus diatur ulang ke nol ketika nomor Mayor berubah.
• Majormenunjukkan versi produk yang Anda gunakan. Misalnya, Mayor dari semua majelis VisualStudio 2008 adalah 9 dan VisualStudio 2010 adalah 10.

Pengecualian terhadap aturan

Selalu ada pengecualian untuk aturan dan Anda harus beradaptasi ketika Anda menemukan mereka. Pendekatan asli saya didasarkan pada penggunaan subversi tetapi baru-baru ini saya telah pindah ke Git. Kontrol sumber seperti subversi dan sumber yang aman yang menggunakan repositori pusat memiliki nomor yang dapat digunakan untuk mengidentifikasi serangkaian sumber tertentu dari waktu tertentu. Ini bukan kasus untuk kontrol sumber terdistribusi seperti Git. Karena Git menggunakan repositori terdistribusi yang ada di setiap mesin pengembangan tidak ada nomor penambahan otomatis yang dapat Anda gunakan, ada peretasan yang menggunakan jumlah check-in tetapi jelek. Karena ini saya harus mengembangkan pendekatan saya.

Major. Minor. Macro.Build

Nomor revisi sekarang telah hilang, build telah bergeser ke tempat revisi sebelumnya dan Makro telah dimasukkan. Anda dapat menggunakan makro sesuai keinginan Anda tetapi sebagian besar waktu saya biarkan sendiri. Karena kami menggunakan TeamCity informasi yang hilang dari angka revisi dapat ditemukan di build, itu berarti ada proses dua langkah tetapi kami tidak kehilangan apa pun dan kompromi yang dapat diterima.

Apa yang harus diatur

Hal pertama yang harus dipahami adalah bahwa Versi Perakitan, Versi File dan Versi Produk tidak harus cocok. Saya tidak menganjurkan memiliki set angka yang berbeda tetapi itu membuat hidup jauh lebih mudah ketika membuat perubahan kecil pada sebuah majelis yang tidak mempengaruhi antarmuka publik yang Anda tidak dipaksa untuk mengkompilasi ulang majelis yang bergantung. Cara saya menangani ini adalah dengan hanya mengatur angka-angka Mayor dan Minor dalam Versi Majelis tetapi untuk mengatur semua nilai dalam Versi File. Sebagai contoh:

• 1.2.0.0 (AssemblyVersion)
• 1.2.3.4 (FileVersion)

Ini memberi Anda kemampuan untuk meluncurkan perbaikan panas yang tidak akan merusak kode yang ada karena versi perakitan tidak cocok tetapi memungkinkan Anda untuk melihat revisi / membangun majelis dengan melihat nomor versi file. Ini adalah pendekatan umum dan dapat dilihat pada beberapa majelis sumber terbuka ketika Anda melihat detail perakitan.

Anda sebagai ketua Tim harus bertanggung jawab untuk menambah nomor minor ketika suatu perubahan yang diperlukan diperlukan. Salah satu solusi untuk meluncurkan perubahan yang diperlukan untuk antarmuka tetapi tidak melanggar kode sebelumnya adalah dengan menandai yang saat ini usang dan membuat antarmuka baru. Ini berarti bahwa kode yang ada diperingatkan bahwa metode ini sudah usang dan dapat dihapus kapan saja tetapi tidak mengharuskan Anda untuk segera merusak semuanya. Anda kemudian dapat menghapus metode usang ketika semuanya telah dimigrasi.

Cara menghubungkannya bersama

Anda dapat melakukan semua hal di atas secara manual tetapi akan sangat memakan waktu, berikut ini adalah cara kami mengotomatiskan prosesnya. Setiap langkah bisa dijalankan.

• Hapus AssemblyVersiondan AssemblyFileVersionatribut dari semua file AssemblyInfo.cs proyek.
• Buat file info rakitan umum (sebut saja VersionInfo.cs) dan tambahkan sebagai item tertaut ke semua proyek Anda.
• Tambahkan AssemblyVersiondan AssemblyFileVersionatribut ke versi dengan nilai "0.0.0.0".
• Buat proyek MsBuild yang membangun file solusi Anda.
• Tambahkan tugas sebelum build yang memperbarui VersionInfo.cs. Ada sejumlah perpustakaan MsBuild sumber terbuka yang menyertakan tugas AssemblyInfo yang dapat mengatur nomor versi. Cukup setel ke angka dan uji sewenang-wenang.
• Tambahkan grup properti yang berisi properti untuk setiap segmen nomor build. Di sinilah Anda mengatur mayor dan minor. Nomor build dan revisi harus diberikan sebagai argumen.

Dengan subversi:

<PropertyGroup>
    <Version-Major>0</Version-Major>
    <Version-Minor>0</Version-Minor>
    <Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
    <Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
    <Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
    <Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>

Semoga saya jelas tapi ada banyak yang terlibat. Silakan ajukan pertanyaan. Saya akan menggunakan umpan balik apa pun untuk menyatukan posting blog yang lebih ringkas.

• Nomor versi dalam rakitan yang dikompilasi
• Paket Ekstensi MSBuild
• TeamCity

[AssemblyVersion] adalah masalah besar di .NET. Satu filosofi, didorong oleh Microsoft adalah Anda membiarkannya bertambah secara otomatis, memaksa semua proyek yang bergantung pada perakitan untuk dikompilasi ulang. Berfungsi jika Anda menggunakan server build. Itu tidak pernah salah untuk dilakukan tetapi waspadalah terhadap orang yang membawa pedang.

Yang lain, yang lebih dekat dikaitkan dengan makna aktualnya adalah bahwa angka tersebut mewakili untuk versi antarmuka publik majelis. Dengan kata lain, Anda hanya mengubahnya ketika Anda mengubah antarmuka publik atau kelas. Karena hanya perubahan seperti itu yang membutuhkan klien dari majelis yang akan dikompilasi ulang. Ini perlu dilakukan secara manual, sistem build tidak cukup pintar untuk secara otomatis mendeteksi perubahan seperti itu.

Anda selanjutnya dapat memperluas pendekatan ini dengan hanya menambah versi saat perakitan dikerahkan pada mesin di luar jangkauan Anda. Ini adalah pendekatan yang digunakan Microsoft, nomor versi .Rakitan mereka sangat jarang berubah. Sebagian besar karena rasa sakit yang sangat besar yang ditimbulkan pada pelanggan mereka.

Jadi apa yang Microsoft khotbahkan bukanlah apa yang dipraktikkannya. Namun proses pembuatan dan kontrol versinya tidak tertandingi, mereka bahkan memiliki insinyur perangkat lunak khusus yang memantau proses tersebut. Tidak cukup berhasil dengan baik, WaitHandle. Menunggu kelebihan beban (int) khususnya menyebabkan rasa sakit yang cukup . Diperbaiki. NET 4.0 dengan pendekatan yang sangat berbeda, tapi itu semakin sedikit di luar cakupan.

Ini terserah Anda dan kepercayaan diri Anda pada seberapa baik Anda dapat mengontrol proses pembuatan dan siklus rilis untuk membuat pilihan Anda sendiri. Selain itu, penambahan otomatis [AssemblyFileVersion] secara otomatis sangat tepat. Namun dengan ketidaknyamanan ini tidak didukung.

Anda dapat menggunakan bagian Bangun dari nomor versi untuk peningkatan otomatis.

[assembly: AssemblyVersion("1.0.*")]

Di lingkungan Anda, versi uji adalah versi yang memiliki versi build! = 0. Pada rilis Anda menambah bagian minor dan mengatur bagian build ke 0, ini adalah bagaimana Anda akan mengidentifikasi rakitan yang dirilis.

Jika Anda memasang perangkat Anda di GAC, GAC Anda akan dibanjiri banyak versi berbeda dari waktu ke waktu, jadi ingatlah itu. Tetapi jika Anda menggunakan dll hanya secara lokal, saya pikir ini adalah praktik yang baik.

Menambah jawaban Bronumskis , saya ingin menunjukkan bahwa setelah standar Semantic Versioning 2.0 di semver.org , Major.Minor.Build.Revisionakan ilegal karena aturan bahwa setelah menambah angka, semua nilai reguler ke kanan harus diatur ulang ke nol.

Cara yang lebih baik mengikuti standar adalah menggunakan Major.Minor+Build.Revision. Ini jelas bukan untuk digunakan AssemblyVersionAttribute, tetapi atribut khusus atau kelas statis dapat digunakan sebagai gantinya.

Semver di TeamCity harus tersedia menggunakan Paket Daya Meta-runner. Untuk git dengan git-flow (terutama di dunia .NET), saya menemukan GitVersion sangat membantu.

Tidak ada aturan yang keras dan cepat ketika datang ke majelis versi, jadi jangan ragu untuk mencoba mana yang akan bekerja untuk Anda, tetapi saya akan menyarankan Anda menggunakan pendekatan 4 bagian karena Anda akan memiliki fleksibilitas flex jika Anda ingin membuat beberapa perubahan di masa depan.

... misalnya: 1.0.0. *

Dicadangkan - Ini menambahkan fleksibilitas tambahan, jika Anda ingin membuat perubahan di masa depan. Tetapi sebagai default, simpan sebagai 0.

Juga, pertimbangkan untuk menandatangani majelis dengan kunci yang kuat. Ini akan menyelesaikan masalah konflik rakitan jika Anda memiliki beberapa versi rakitan yang terdaftar di GAC. Tautan MSDN