Versi semantik dalam Agile

Katakanlah saya memiliki 14 hari sprint iterasi di mana saya memiliki beberapa cerita untuk fitur baru, beberapa perbaikan dan beberapa bug untuk diperbaiki. Saya juga menggunakan perubahan itu ketika sudah siap, saya tidak menunggu akhir dari sprint.

Masalah saya adalah - bagaimana cara melacak versi semantik dari produk yang dikembangkan dan dipelihara seperti ini? Jika akan ada rilis setiap 14 hari itu akan mudah, saya akan menambah nomor versi dan mencatat semua perubahan di changelog. Tetapi bagaimana jika perubahan digunakan secara terus menerus? Haruskah ada peningkatan versi setiap kali sesuatu dikerahkan? Atau haruskah saya menunggu sampai sprint berakhir dan setelah ini, membuat beberapa "resume" dan menambah nomor versi hanya sekali per iterasi secara mandiri pada penyebaran yang sebenarnya? Apa praktik terbaik untuk versi semantik di Agile?

EDIT: Untuk lebih menjelaskan kebutuhan saya, saya ingin changelog untuk pemangku kepentingan di tempat pertama. Saya tidak berpikir mereka akan tertarik pada catatan baru di changelog setelah setiap perubahan dikerahkan.

Untuk manajemen rilis yang umum, Anda akan menginginkan nomor build yang dihasilkan oleh sistem build Anda sehingga DLL diversi setiap kali mereka digunakan. Ini akan memastikan Anda nanti dapat memeriksa versi mana yang digunakan pada server yang diberikan.

Versi 'pemasaran' Anda, yang biasanya dimasukkan ke dalam catatan rilis atau dipublikasikan ke situs Anda tidak harus diperbarui setiap versi. Catatan rilis itu harus diakumulasikan dan dikelompokkan bersama, kemungkinan waktunya dengan akhir sprint Anda.

Jika skema versi semantik klasik "MAJOR.MINOR.PATCH" masuk akal, tergantung pada siapa Anda menyebarkan, dan terutama kapan dan seberapa sering Anda menyebarkan ke pengguna akhir . Skema ini paling berguna jika Anda bekerja dengan rilis stabil "4.5", di mana Anda mulai dengan 4.5.0. Versi 4.5.1, 4.5.2, dan seterusnya hanya berisi perbaikan bug, sementara Anda secara internal sudah bekerja pada versi 4.6.

Misalnya, jika Anda memberikan "cabang stabil" kepada pengguna akhir Anda, berikan versi 4.5.0 untuk penyebaran awal, dan 4.5.1, 4.5.2 setiap kali Anda merilis patch. Dalam pengembangan "agile" internal dan penyebaran mid-sprint, Anda sudah dapat memiliki versi 4.6, sebut saja "versi beta". Setiap kali Anda menyebarkannya di sprint tengah, tambahkan nomor build yang dibuat secara otomatis seperti "4.6.beta build 123". Ketika sprint Anda berakhir, tetapkan "4.6.0", dan alihkan nomor versi untuk sprint berikutnya secara internal ke "4.7". Memulai dengan ".0" hanya sebuah konvensi, Anda juga dapat menggunakan ".0" untuk menandai versi-beta, dan mulai dengan ".1" untuk pengguna akhir Anda. IMHO kata "beta" jauh lebih ekspresif, memberi tahu semua orang sprint "belum selesai".

Jika Anda merilis log perubahan pengguna akhir lengkap dengan setiap versi beta terserah Anda, tetapi setidaknya pada akhir sprint log perubahan harus diselesaikan, dan setiap kali Anda memberikan perbaikan bug kepada pengguna akhir, Anda juga harus memperbarui dokumen sejarah.

Anda akan menemukan strategi melepaskan dua cabang yang terpisah, satu cabang "stabil" dengan nomor versi semantik, dan "cabang pengembangan" yang ditandai dengan nomor bangun atau yang serupa, di banyak produk sumber terbuka seperti Inkscape, Firefox atau 7-zip.

Namun, jika Anda tidak bekerja dengan cabang stabil dan pengembangan yang terpisah, dan merilis versi baru kepada Anda pengguna akhir setiap hari, Anda juga harus menambah nomor versi setiap hari. Untuk kasus seperti itu, nomor versi "4.5.1", "4.5.2", ... mungkin akan mencerminkan penerapan individual Anda, dan tidak menunjukkan perbedaan antara perbaikan bug dan perubahan lainnya. Itu bisa ok, itu tidak klasik "versi semantik" lagi. Dalam skenario ini, Anda juga bisa menggunakan versi 4.5, 4.6, 4.7, 4.8, yang tidak memberikan perbedaan nyata.

Mengenai pertanyaan Anda tentang entri di changelog Anda: IMHO ketika sesuatu terlihat oleh pengguna akhir, ada baiknya entri di changelog, segera setelah Anda menerapkan perubahan. Misalnya, jika Anda menggunakan fitur toggle dan membuat perubahan pada beberapa fitur setengah-panggang yang belum diaktifkan untuk pengguna, itu tidak termasuk ke dalam changelog. Jika Anda hanya melakukan refactoring, tanpa ada perubahan yang terlihat kepada pengguna, itu bukan milik changelog. Jika Anda memperbaiki bug yang dapat mempengaruhi beberapa pengguna, itu pasti masuk ke changelog - dan itu harus disebutkan di sana pada saat yang sama ketika Anda menggunakan perbaikan bug. Dan tidak masalah jika Anda merilis harian atau bulanan atau tahunan.

Saya akan menggunakan nomor build. Biasanya nomor build akan sesuai dengan versi tertinggi dari sistem kontrol versi. Jika nomor build hari Senin adalah 1745 dan telah diperiksa 5 perubahan selama selasa, jumlah build malam hari akan menjadi 1750.

Kemudian buat ringkasan singkat untuk apa yang telah berubah antara 1745 dan 1750.

Kemudian setiap kali Anda memperbarui nomor versi sistem Anda, Anda bisa menjumlahkan semua ringkasan pendek dari build untuk mendapatkan perubahan dari nomor versi terakhir ke yang baru.

Metode pilihan saya yang telah saya gunakan selama setidaknya beberapa tahun sekarang adalah untuk menambah nomor setelah setiap cerita selesai. Ini berarti bahwa versi yang dirilis pada akhir sprint tidak akan berkelanjutan, mis. Setelah 1.2.3 Anda mungkin menemukan 1.5.2 daripada 1.4.0.

Di changelog Anda dapat mendaftar versi perantara dengan deskripsi yang sesuai atau hanya mengelompokkan semua perubahan ke versi "dirilis" dan melewati versi di antaranya.

Awalnya, saya khawatir pengguna akan menemukan "lubang" antara nomor versi bermasalah, tetapi begitu mereka mengetahuinya, itu bukan masalah dalam praktiknya. Keuntungan besar adalah bahwa meningkatkan jumlah setelah setiap cerita membuat proses lebih sedikit rawan kesalahan - Anda tidak perlu memeriksa seluruh pekerjaan dari 2 minggu untuk memutuskan apa yang akan nomor versi berikutnya - ketika melihat satu cerita, itu jelas . Selain itu, "lompatan" dalam nomor versi antara setiap rilis memberikan perkiraan kasar tentang berapa banyak perubahan masuk ke rilis. Semua dalam semua, saya telah menemukan sistem ini berfungsi dengan baik (ini dengan pelanggan internal perusahaan, tetapi jika Anda sudah bekerja dalam siklus rilis tangkas itu harus bekerja untuk pelanggan eksternal juga).