git-flowによる継続的な統合と継続的な配信

Question

私たちはパイプラインのトリガーとしてSubversionをコミットしてしばらくしてから、継続的な統合と継続的な配信を行ってきました。最近、私たちはgit-flowのいくつかのプロジェクトでgitを使い始めました。継続的な統合と継続的な配信パイプラインをトリガするためにgit-flowのどの分岐を使うべきかを決定しようとしています。

はここで二つのアプローチです：

1.ブランチ開発

問題：gitのフローでは、我々は生産のリリース（またはマスター）ブランチを展開することになっているので、我々がしなければなりません連続的な統合（ブランチ展開）と連続配信（ブランチマスタ）の2つの異なるパイプラインを構築します。これは、生産のバージョンが他の環境のもの（統合、テスト、ステージング）と同じではないため、生産にバグを導入する可能性があります。

2.マスターブランチ：

問題：これらのブランチへの変更はありません非常に頻繁にプッシュされますので、この方法では、我々は、真に継続的インテグレーションを持っていないでしょう。

パイプラインで使用するリッジブランチはどれですか？

Answer 1

真実は2つの間にあります。

開発ブランチコミットのたびに、CIサーバを自動的に実行させます。リリースブランチを作成し、すべてのテストを実行します。

失敗した場合は、ブランチを報告および/または削除します。そうでない場合は、それをmasterにマージします。

基本的なアイデアは、Java Mavenプロジェクト（BDD in Action、Jenkins Definite Guide）のCI/CDに関するJohn Ferguson Smartのスライドから来ています。

Answer 2

私の見解では、継続配信でgit-flowを適用する場合は、最初のアプローチで述べたように2つの異なるパイプラインが必要です。

私はこのアプローチをお勧めしたい：とすぐに機能がマージまたはプルに（開発ブランチに追加されます。

1.ブランチがコミットビルドをトリガーする開発ブランチ

• を開発CI）は、ビルド、テスト（ユニットテスト&コードリビジョン）とソリューション（ "-develop-vX"接尾辞付き）をパッケージ化します。したがって、チームは失敗した場合に迅速に反応することができます。
• コミットビルドが正常に終了すると、タスクが完了します（そうしないと、変更は元に戻り、変更をコミットした開発者は直ちにそれを修正する必要があります）。並行して、受け入れテストステージは、開発者の作業を妨害することなく受け入れテストスーツ（例えば、機能性&回帰テスト）を実行するために、前のビルドを開発環境に展開することを開始する。作業が完了すると、開発ブランチのステータスがチームに伝えられます。したがって、チームは現在のSprintの間にソリューションの安定性を認識しています。受入れテストステージが正常に終了すると、製品はマスターブランチとマージする準備が整います（それ以外の場合は修正されます）。

2.マスターブランチ

• スプリントは、安定した開発ブランチを終了すると（それが安定だ）合併とマスターブランチにタグ付けされています。したがって、マスターブランチは、ソリューションをビルドし、テストし、展開するためのトランクコミットビルドをトリガーします（パッケージはリリース候補またはマスターサフィックスと共に格納されます）。
• トランクコミットビルドが正常に完了すると（動作するはずです）、受け入れテストステージは統合環境に対する受け入れテストを展開して検証します。そして、成功の場合、新しいバージョンは生産の準備ができています。それ以外の場合、コミットビルドまたは受け入れテストステージでエラーが発生した場合、マージは元に戻されます。

Answer 3

Gitフローと継続的な統合は、定義上、互換性がありません。ブランチは、インテグレーションを遅らせるためのメカニズムです：マスター以外のブランチ（Subversionから来た場合はトランク）にコミットすると、継続的な統合は避けられます。継続的な統合は簡単ですが、容易ではありません。