アジャイルでのセマンティックバージョニング


10

14日間のスプリントの反復があり、新機能、いくつかの改善点、および修正すべきバグのストーリーがいくつかあるとします。また、準備が整ったときにこれらの変更をデプロイします。スプリントの終了を待ちません。

私の問題は、このように開発および保守された製品のセマンティックバージョニングを追跡する方法ですか?14日ごとにリリースされる場合は簡単ですが、バージョン番号を増やし、すべての変更を変更ログに記録します。しかし、変更が継続的にデプロイされるとどうなるでしょうか。何かがデプロイされるたびにバージョンを上げる必要がありますか?または、スプリントが終了するまで待ってから、「再開」して、実際の展開で独立して反復ごとに1回だけバージョン番号を増やす必要がありますか?アジャイルのセマンティックバージョニングのベストプラクティスは何ですか?

編集:私のニーズをよりよく説明するために、私は最初に利害関係者の変更ログを求めています。変更がデプロイされるたびに、変更ログの新しいレコードに関心を持つことはないと思います。



「セマンティックバージョニング」とはどういう意味ですか?versionnumnerでビルド日と時間?
k3b 2015

2
@ k3b:Googleを試してください。semver.orgに
Doc Brown

3
スプリント中盤で誰に配備しますか?直接エンドユーザーに?一部のテスターに​​は?
Doc Brown

@DocBrownを直接エンドユーザーに提供します。何かが完了すると、本番環境にデプロイされます。
PavelŠtěrba15年

回答:


7

通常のリリース管理では、ビルドシステムによってビルド番号が生成され、DLLが展開されるたびにバージョンが付けられるようにします。これにより、特定のサーバーにデプロイされているバージョンを後で確認できるようになります。

「マーケティング」バージョンは、通常リリースノートに記載されているか、サイトに公開されていますが、バージョンごとに更新しないでください。これらのリリースノートは蓄積し、グループ化する必要があります。おそらく、スプリントの終了時に合わせます。


はい、この「マーケティング」バージョンの変更ログはまさに私が必要としているものです。技術者以外の関係者でも読みやすくします。
PavelŠtěrba15年

6

従来のセマンティックバージョニングスキーム「MAJOR.MINOR.PATCH」が意味をなすかどうかは、誰にデプロイするか、特にエンドユーザーにいつどのくらいの頻度でデプロイするかに依存します。このスキームは、4.5.0で始まる安定版リリース「4.5」で作業する場合に最も役立ちます。バージョン4.5.1、4.5.2などにはバグ修正のみが含まれていますが、内部ではすでにバージョン4.6で作業しています。

たとえば、エンドユーザーに「安定したブランチ」を提供する場合、初期デプロイメントにはバージョン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つはビルド番号などのマークが付いた「開発ブランチ」をリリースする戦略が見つかります。

ただし、stableブランチと開発ブランチを別々に使用せず、新しいバージョンをエンドユーザーに毎日リリースする場合は、バージョン番号も毎日増やす必要があります。そのような場合、バージョン番号「4.5.1」、「4.5.2」、...はおそらく個々のデプロイメントを反映し、バグ修正と他の変更との違いを示しません。それは大丈夫かもしれません、それはもはや古典的な「セマンティックバージョン管理」ではありません。このシナリオでは、バージョン4.5、4.6、4.7、4.8をデプロイすることもできますが、実際の違いはありません。

変更ログのエントリに関する質問:エンドユーザーに何かが見える場合のIMHO変更をデプロイするとすぐに、変更ログにエントリする価値があります。たとえば、機能トグルを使用して、ユーザーに対してまだアクティブ化されていないハーフベイク機能に変更を加えた場合、変更ログには含まれません。ユーザーに目に見える変更がなく、リファクタリングのみを行う場合、それは変更ログには含まれません。一部のユーザーに影響を与える可能性のあるバグを修正する場合、それは間違いなく変更ログに属します-バグ修正をデプロイするときに、同時にそこに記載する必要があります。そして、あなたが毎日、毎月、または毎年リリースするかどうかは関係ありません。


3

ビルド番号を使用します。通常、ビルド番号はバージョン管理システムの最新バージョンに対応します。月曜日のビルド番号が1745で、火曜日に5つの変更が確認された場合、火曜日の夜のビルド番号は1750になります。

次に、1745年から1750年の間に変更された点について短い要約を作成します。

その後、システムのバージョン番号を更新するたびに、ビルドからのすべての短い要約を合計して、最後のバージョン番号から新しいバージョンへの変更を取得できます。


3

私が少なくとも数年間使用してきた私の好ましい方法は、各ストーリーが完了した後に数を増やすことです。これは、スプリントの最後にリリースされたバージョンが継続的ではないことを意味します。たとえば、1.2.3以降は、1.4.0ではなく1.5.2となる場合があります。

変更ログでは、中間バージョンを対応する説明とともにリストするか、すべての変更を「リリースされた」バージョンにグループ化して、その間のバージョンをスキップできます。

最初は、ユーザーがバージョン番号間の「穴」に問題があると思うのではないかと心配していましたが、それを知ってしまえば、実際には問題になりません。大きな利点は、各ストーリーの後に番号を増やすと、プロセスでエラーが発生しにくくなることです。2週間の作業全体をチェックして次のバージョン番号を決定する必要はありません。単一のストーリーを見ると、明らかです。さらに、各リリース間のバージョン番号の「飛躍」は、リリースに加えられた変更の数の概算を示します。全体として、私はこのシステムがうまく機能することを発見しました(これは会社内部の顧客でしたが、アジャイルリリースサイクルで既に作業している場合は、外部の顧客でも機能するはずです)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.