git-flowによる継続的な統合と継続的な配信
パイプラインがトリガーとしてSubversionがコミットされるようになってから、継続的な統合と継続的な配信を行ってきました。最近、いくつかのプロジェクトで git-flow を使用してgitの使用を開始し、git-flowのどのブランチを使用して継続的な統合と継続的な配信パイプラインをトリガーするかを決定しようとしています。
以下に2つのアプローチを示します。
1。開発ブランチを使用
問題：git-flowでは、リリース（またはマスター）ブランチを実稼働環境にデプロイすることになっているため、2つの異なるパイプラインを構築する必要があります。1つは継続的統合（ブランチ開発）と1つは継続的配信（ブランチマスター）です。本番環境のバージョンは他の環境（統合、テスト、ステージング）のものと同じではないため、これにより本番環境にバグが発生する可能性があります。
2。マスターブランチを使用：
問題：この方法では、これらのブランチへの変更があまり頻繁にプッシュされないため、真に継続的な統合ができません。
パイプラインで使用する適切なブランチはどれですか？
Gitフローと継続的な統合は、定義上、互換性がありません。ブランチはdelaying integration：のメカニズムです。マスター（またはSubversionから来た場合はトランク）以外のブランチにコミットするとき、継続的な統合を避けています。継続的な統合は簡単ですが、簡単ではありません。
真実は2つの間にあります。厳密なCDパイプラインでgit-flowを採用する場合は、CIのリリースブランチを使用する必要があります。
- 開発ブランチコミット（のすべて）に対して、CIサーバーにリリースブランチを自動的に作成させ、すべてのテストを実行します。
- 失敗した場合は、ブランチをレポートおよび/または削除します。それ以外の場合は、マスターにマージします。
基本的なアイデアは、Java MavenプロジェクトでのCI/CDに関するJohn Ferguson Smartのスライド（BDD in Action、Jenkins Definite Guide）に基づいています。
私の見解では、連続配信でgit-flowを適用する場合、最初のアプローチで述べたように2つの異なるパイプラインが必要です。
このアプローチをお勧めします：
1。ブランチの開発
- 開発ブランチは、ビルドのコミットをトリガーします。機能が開発ブランチに追加されるとすぐに（マージまたはプルリクエストで）、CIはソリューションをビルド、テスト（ユニットテストとコードリビジョン）、パッケージ化します（「-develop- vX」サフィックス）。したがって、チームは障害が発生した場合に迅速に対応できます。
- コミットビルドが正常に完了すると、タスクが完了します（それ以外の場合、変更は元に戻され、変更をコミットした開発者はすぐに修正する必要があります）。並行して、受け入れテストステージは、開発者の作業をブロックせずに受け入れテストスーツ（機能テストおよび回帰テストなど）を実行するために、開発環境への以前のビルドの展開を開始します。完了すると、開発ブランチのステータスがチームに通知されます。したがって、チームは現在のスプリント中のソリューションの安定性を認識しています。受け入れテストステージが正常に終了すると、製品はMasterブランチとマージできる状態になります（そうでない場合は修正されます）。
2。マスターブランチ
- Sprintが完了すると、安定版のDeveloperブランチ（安定版）がマージされ、Masterブランチにタグ付けされます。そのため、マスターブランチは、ソリューションをビルドし、テストし、展開用にパッケージ化するトランクコミットビルドをトリガーします（パッケージは、リリース候補またはマスターサフィックスと共に保存されるようになりました）。
- トランクコミットビルドが正常に完了すると（正常に機能するはずです）、受け入れテストステージが統合環境に対して受け入れテストを展開および検証します。そして、成功した場合は、新しいバージョンの生産準備が整います。それ以外の場合、ビルドのコミットまたは受け入れテストの段階でエラーが発生すると、マージは元に戻されます。