ブランチ戦略†
ソースコード管理実践によって実現したいことは次の3つ。
- リリースパッケージを常時ビルド可能
- コードは安定していると言うことが可能
- 安全にリリース可能
1. リリースパッケージを常時ビルド可能†
リリース時点をリビジョン番号で切り出すことは可能です。しかし、現時点のリリースパッケージにバグフィックスを適用したいようなとき、よく考えずにリビジョン番号で切り出しをすると次のテーマと整合性を保つことが困難になります。既にコードラインが次のテーマとして進行している場合、バグフィックスの適用を次のテーマについても考える必要があるからです。また、それでも次のテーマは進行させなければならないのです。
ここでとりわけ解決したいユースケースは次です。
- リリース済みの現時点パッケージにバグフィックスだけを適用してリリースする
- 前テーマのリリースを待たず次テーマの開発を進行する
2. コードは安定していると言うことが可能†
ソースコードをマージした後のコードラインは安定していると言うことができません。マージしたコードがマージ先にどのような影響があるかを完全に把握することは困難だからです。従って、とりわけ IT や ST フェーズは次のことを目的にしてテストを実施するべきです。すなわち、開発分の変更をマージしたあとのコードラインを安定にする、ということです。
ここでとりわけ解決したいユースケースは次です。
- 意義のある各テスト(UT, IT, ST)を実施する
- 複数テーマの開発を並行する
3. 安全にリリース可能†
安全にリリースパッケージを用意するには俗人性を排除する必要があります。俗人性のない形式化によって、誰でも、同時に、ブランチの状態を評価できなければならないからです。従って、この取り組みそのものが安全なリリースをもたらします。
ここでとりわけ解決したいユースケースは次です。
- 誰もがブランチ計画を立てる
- 誰もがリリースパッケージを用意する
- 誰もがブランチ実践を引き継ぐ