特定のシナリオのために、現在の職場の git-flow モデルを拡張することを考えています。しかし、私のシナリオは非常に一般的であるため、git-flow モデルで誰もこれを行ったことがないことに驚いています。これにより、明らかな問題を見逃したと思います。私の質問は: 私の提案した拡張機能に欠陥はありますか?
シナリオ: 共通のコードベースから開発する開発チームが多数あり、いくつかの (永続的な) 環境を通じてリリースをプッシュします。最初はシステム統合環境 (SIT)、次に UAT 環境、そしてプリプロダクションです。 、そしていよいよ本番へ。これは厳密に順番に行われますが、どのリリース候補もどの環境でも失敗する可能性があり、それ以上進めない可能性があります。したがって、後の各環境は、前の環境の動きの遅いバージョンにすぎません。
ソース管理に git を導入しています。ワークフローが必要です。git-flow は良いスタートのようです。
私たちは、いつでも各環境にあるものをキャプチャする方法 (つまり、知る方法) を自問しました。git-flow モデルには、本質的に 2 つのコア状態があるようです:masterとdevelop. 彼らは「無限の寿命」を持っています。他のブランチは、「期間限定」の「サポート ブランチ」にすぎません。これらは、開発を許可し、(一時的なリリース状態を介して) 開発から実稼働に移行するためだけに存在します。git-flow モデルは、開発からリリースへの移行に基づいています。
ただし、これは、多段階のリリース シーケンスを使用して、シナリオに論理的に対応していません。developもちろん支店でも大丈夫です。そして、masterブランチは明らかに本番環境に対応しています。元のgit-flow の説明には、次のように書かれていmasterます。
したがって、変更がマスターにマージされるたびに、これは定義上、新しい製品リリースになります。これには非常に厳密な傾向があるため、理論的には、Git フック スクリプトを使用して、マスターでコミットが発生するたびに、ソフトウェアを自動的にビルドして運用サーバーにロールアウトできます。
は生産の継続的な記録であるため、SIT、UAT、および pre-prod に対応するブランチを持つように git-flow モデルを拡張するmaster必要があることは一貫しているようです。結局のところ、これらは永続的な環境であり、厳密なリリース手順が適用されます。それらは、本番環境よりも少し速く変化します。
これらの追加の永続的なブランチは、対応する環境と同様に、 と の間に位置しますdevelop。master
これは、各環境へのリリースと各環境の状態を簡単に追跡できることを意味します。また、それぞれのマージも簡単ですdevelop。SIT ブランチには からのマージが必要であり、UAT ブランチには SIT ブランチからのマージが必要であり、pre-prod ブランチには UAT ブランチからのマージが必要であり、最後にmasterブランチ (本番用) にはpre-prod ブランチからのマージ。後の各分岐は、単に前の分岐の動きが遅いバージョンです。
私は何かを逃しましたか？