継続的デリバリー、1回ビルド、または環境ごとにビルド
現在、ソフトウェアを構築するための最良のプロセスについて、チーム内で議論があります。私のチームはgitflowに従って、デプロイメントパイプラインの開始時に一度ビルドし、各環境でそのビルドを促進しています。
他のチームは、Pre-PRODからPROへのビルドを促進する製品を除いて、環境ごとに1回ビルドします。彼らは環境ごとにブランチを持っており、機能をより高いレベルの環境に移動したい場合、コードを正しいブランチにマージしてビルドをトリガーします。
私のアプローチは正しいと非常に強く感じています（！）。CI/CDに関する本を何冊か読んだことがあり、ほとんどすべてが1つを構築し、宣伝するというコンセプトから始まります。しかし、私のアプローチにはかなりの抵抗があり、両方のアプローチをより幅広い聴衆に向けて鳴らしたいと思っています。これまでに上げられたものに対するポイントは次のとおりです。
- 欠陥修正は、より高いレベルの環境に直接入れることはできず、完全なパイプラインを通過する必要があります（これは良いことだと思います！）
- マスターブランチが本番環境の内容を反映していないことを保証することはできません（リリースブランチをデプロイ時にマスターにマージするのはなぜなのか、よくわかりません）
したがって、私が正しく理解している場合、チームのアプローチは、最初にバイナリを作成し、次にプッシュしてテスト、プリプロダクション、そして最終的には同じバイナリを使用してプロダクションすることです。他のチームのアプローチは、ブランチを使用してさまざまな環境を反映し、実行することですそれらのブランチからの継続的なビルド？
私はあなたに同意しますが、これらのことは常にあるので、この考えには賛否両論があることを考慮してください。あなたがあなたのアイデアをプッシュするなら、あなたはあなたのアプローチの問題とあなたの支持のポイントに気づくべきです：
長所：
- プログラムの動作は変更されません、あなたはそれが保証されています。変更が構成ファイルまたはデータベースである場合は、構成ファイルとデータベースパラメーターが同じであることを確認するだけで、運用前に機能する問題の修正を保証できます（小さな利点はありません）。
- このアプローチは、もう少し堅牢です。ブランチシステムにも、使用する構成とデータベースパラメータのシェアがあると想定していますが、ブランチコード自体を変更して修正を適用することもできます。これには利点がありますが、ビルドワンスシステムとは逆に、anythingは異なる可能性があるため、本番環境での問題の原因を見つけることは、評価において非常に困難になります。
短所：
- 製品のバグある迅速な修正が面倒。問題にコードの実際の変更が必要であると想定すると、テストを再コンパイルし、テストを通じて本稼働前に、および本稼働前から本番にプッシュする必要があります。これは完全にbadの問題ではありません。安全であるためです。ただし、管理者は安全性を完全に無視し、迅速な修正を優先する傾向があります。クライアントは、修正を完全にテストしてからリリースするまで待機する必要があることを説明します。お勧めしません。
- ユニットテストは、環境ごとのビルドソリューションと同じくらい可能性が非常に高くなりますが、セットアップは多少厄介です。つまり、単にバイナリを使用することはできません。おそらく、ソースリポジトリのトランクでそのバージョンにタグを付け、それを参照として使用する必要があります。
ここで重要な点は、堅牢性と安全性とリリース効率であり、会社にとってより重要であるように思えます。環境ごとのビルドシステムを使用してショートカットが許可されている場合（そして、よくわかっている場合は、迅速に修正するために運用ブランチを直接更新する可能性が高い）、最終的に問題が発生すると、会社の費用がさらに増えると良い議論をする可能性があります。将来の問題では、最初に修正に多くの時間を費やすために会社にコストがかかり、遡及的に会社の評判を損なうことはありません防止バグ。
これが失敗した場合、本番環境にジャンプするだけでテストを実行できる緊急事態が発生した場合に備えて、ビルドをプリプロダクションに直接移行して緊急修正を行う可能性があります。
最も重要なのは、この問題に摩擦を生じさせる価値がないため、柔軟に他の点に耳を傾けることです。結局、あなたは会社の最善の利益になるものだけを望み、あまりにも多くの抵抗を提供することは会社にとってあまり生産的ではなく、いかなる場合でもあなたによく反映しません。
お役に立てば幸いです。