アジャイルでのセマンティックバージョニング
14日間のスプリントの反復があり、新しい機能に関するいくつかのストーリー、いくつかの改善点、修正すべきバグがあるとします。また、準備ができたときにこれらの変更をデプロイします。スプリントの終了を待ちません。
私の問題は、このように開発および保守された製品のセマンティックバージョニングを追跡する方法ですか？ 14日ごとにリリースされる場合は簡単ですが、バージョン番号を増やして、すべての変更を変更ログに記録します。しかし、変更が継続的にデプロイされるとどうなるでしょうか。何かがデプロイされるたびにバージョンを上げる必要がありますか？または、スプリントが終了するまで待ってから、「再開」して、実際の展開で独立して反復ごとに1回だけバージョン番号を増やす必要がありますか？ アジャイルでのセマンティックバージョニングのベストプラクティスは何ですか？
編集：私のニーズをよりよく説明するために、最初に利害関係者の変更ログを求めています。変更がデプロイされるたびに、変更ログの新しいレコードに関心を持つことはないと思います。
一般的なリリース管理では、ビルドシステムによってビルド番号が生成されるようにして、DLLが展開されるたびにバージョンが付けられるようにします。これにより、特定のサーバーにデプロイされているバージョンを後で確認できるようになります。
通常はリリースノートに記載されているか、サイトに公開されている「マーケティング」バージョンは、各バージョンを更新しないでください。これらのリリースノートは蓄積し、グループ化する必要があります。おそらく、スプリントの終了時に合わせます。
従来のセマンティックバージョニングスキーム「MAJOR.MINOR.PATCH」が意味をなすかどうかは、誰にデプロイするか、特にいつ、どのくらいの頻度でエンドユーザーにデプロイするかに依存します。このスキームは、4.5.0から始める安定リリース "4.5"で作業する場合に最も役立ちます。バージョン4.5.1、4.5.2などにはバグ修正のみが含まれていますが、内部ではすでにバージョン4.6で作業しています。
たとえば、エンドユーザーに「stableブランチ」を提供する場合、初期デプロイメントにはバージョン4.5.0を、パッチをリリースするときは常に4.5.1、4.5.2を提供します。内部の「アジャイル」開発とミッドスプリントの展開では、すでにバージョン4.6を使用できます。これを「ベータ版」と呼んでください。スプリントの途中でデプロイする場合は常に、「4.6.beta build 123」のような自動生成されたビルド番号を追加します。スプリントが終了したら、それに「4.6.0」を割り当て、次のスプリントのバージョン番号を内部的に「4.7」に切り替えます。 「.0」で始まるのは慣例にすぎません。ベータ版のタグ付けに「.0」を使用し、エンドユーザーの場合は「.1」で始めることもできます。私見の単語「ベータ版」ははるかに表現力豊かで、すべてのスプリントが「まだ完了していない」と伝えています。
ベータ版のバージョンごとに完全なエンドユーザー変更ログをリリースする場合は、少なくともスプリントの最後に変更ログを完了し、エンドユーザーにバグ修正を提供するたびに更新する必要があります。履歴ドキュメント。
Inkscape、Firefox、7-Zipなどの多くのオープンソース製品では、2つの分離したブランチ、1つはセマンティックバージョン番号が付いた「安定した」ブランチ、もう1つはビルド番号などのマークが付いた「開発ブランチ」をリリースする戦略を見つけます。
ただし、個別の安定版ブランチと開発ブランチを使用せず、新しいバージョンをエンドユーザーに毎日リリースする場合は、バージョン番号も毎日増やす必要があります。そのような場合、バージョン番号「4.5.1」、「4.5.2」、...はおそらく個々のデプロイメントを反映しており、バグ修正と他の変更との違いを示していません。それは大丈夫かもしれません、それはもはや古典的な「セマンティックバージョン管理」ではありません。このシナリオでは、バージョン4.5、4.6、4.7、4.8をデプロイすることもできますが、実際には違いはありません。
変更ログのエントリに関する質問について：エンドユーザーに何かが見える場合のIMHO変更をデプロイするとすぐに、変更ログにエントリする価値があります。たとえば、機能トグルを使用して、ユーザーに対してまだアクティブ化されていないハーフベイク機能に変更を加えた場合、変更ログには含まれません。ユーザーに目に見える変更がなく、リファクタリングのみを行う場合、それは変更ログに属しません。一部のユーザーに影響を与える可能性のあるバグを修正する場合、それは間違いなく変更ログに属します-バグ修正をデプロイするときに、同時にそこに記載する必要があります。そして、あなたが毎日、毎月、または毎年リリースするかどうかは関係ありません。
ビルド番号を使用します。通常、ビルド番号はバージョン管理システムの最新バージョンに対応します。月曜日のビルド番号が1745で、火曜日に5つの変更が確認された場合、火曜日の夜のビルド番号は1750になります。
次に、1745年から1750年の間に変更された点について短い要約を作成します。
その後、システムのバージョン番号を更新するたびに、ビルドからのすべての短い要約を合計して、最後のバージョン番号から新しいバージョンへの変更を取得できます。
私が少なくとも数年間使用してきた私の好ましい方法は、各ストーリーが完了した後に数を増やすことです。つまり、スプリントの最後にリリースされたバージョンは継続的ではありません。 1.2.3以降、1.4.0ではなく1.5.2が見つかる場合があります。
変更ログでは、中間バージョンを対応する説明とともにリストするか、すべての変更を「リリースされた」バージョンにグループ化して、その間のバージョンをスキップできます。
最初は、ユーザーがバージョン番号間の「穴」に問題があると思ったのではないかと心配していましたが、それがわかったら、実際には問題になりません。大きな利点は、各ストーリーの後に番号を増やすと、プロセスでエラーが発生しにくくなることです。2週間の作業全体をチェックして次のバージョン番号を決定する必要はありません。単一のストーリーを見ると、明らかです。さらに、各リリース間のバージョン番号の「飛躍」は、リリースに加えられた変更の数の概算を示します。全体として、私はこのシステムがうまく機能することを発見しました（これは会社内部の顧客でしたが、アジャイルリリースサイクルで既に作業している場合は、外部の顧客でも同様に機能するはずです）。