典型的な解決策は、CI (Continuous Integration) ビルドをビルド サーバーで実行することです。これは、ソース コードを分析し、(デバッグで) ビルドしてテストを実行し、テスト カバレッジを測定します。
現在、一般的に知られている別のビルド タイプは「Nightly ビルド」です。コード ドキュメントの作成、セットアップ パッケージの作成、テスト環境へのデプロイ、テスト環境に対する自動 (スモークまたは受け入れ) テストの実行などの遅い作業を行います。
さて、質問：
あなたの会社では何を使っていますか？
(リリース ビルドでは、潜在的な製品バージョンのソース管理にある種のタグも追加する必要があります。)
通常、私が行う方法は、ナイトリー ビルドをリリース ビルドに昇格させることです。通常、別のリリース ビルドを作成することは望ましくありません。ほとんどの QA チームはナイトリー ビルドをテストする必要があります (CI ビルドからテストしないことを願っています)。彼らがそれをリリースするのに十分であると判断したら、あなたはそれをリリース状態に昇格させます。それが何を意味するかはあなたが判断します。別の場所に移動し、名前を変更し、タグを付け、ラベルを付け、書き込みます。
QA に毎晩テストしてもらいたくない場合は、彼らがそれでよいと判断したときに、別のものを作成します。あなたは決して知りません、それらは異なる場合があります。ビルド マシンに OS パッチが適用されたり、サード パーティのツールが更新されたりした可能性があります。「まったく同じビルド」をテストするために、QA チームに 2 回の作業をさせたくありません。同じソースからのものである可能性がありますが、まったく同じビルドであるという保証はありません。
あなたの質問に対する答えは、取り組んでいるプロジェクトと設定したい目標によって大きく異なります。
一般に、(小規模なプロジェクトの場合は当然のことですが) ビルドは非常に高速である必要があり、展開に必要なものがすべて含まれている必要があります。これは私にとって常に目標であり、たとえ達成できなくても、少なくとも一度はそうではありません。常に改善できることを見続けているだけです。
大規模なレガシー プロジェクトに取り組んできた経験から、非常に多くの問題が蓄積されて物事の速度が低下し、実現不可能になる可能性があることを知っています。少なくとも当面のターゲットとしてではありません。大規模なレガシー プロジェクトでは、通常、コンパイルとリンクに時間がかかりすぎます。テスト (存在する場合) も実行に時間がかかりすぎる可能性があり、展開に必要なすべての情報の生成も遅く、手動でさえある可能性があります。また、ビルド ハードウェアが不十分である可能性があります。この不完全なリストに追加するものは他にもたくさんあります。
このようなプロジェクトに取り組むときは、別々のサイクルで作業を行うようにしています。
最初のサイクル、ビルド、自動化された単体テストの実行、ビルドのパッケージ化、およびアーカイブを行う堅牢なCI サーバー。これは、行われた変更に関する開発への迅速なフィードバックを提供するために高速である必要があります。これが遅い場合は、ビルド用のより良いハードウェアを入手し、依存関係を整理し、遅い単体テストを修正するなどしてください。これをできるだけ速くしたいと考えています。ビルドはすべてデプロイ可能なビルドです。
2 番目のサイクルは、CI システムによって作成されたビルドのみをピックアップする、より遅いサイクルになります。ソース コードを入力として使用するのではなく、リリース ビルドを使用します。これらは、必要に応じて (ビルドが生成されるたびに) ピックアップされるか、別のサイクルを実行する準備ができたときに最新のものを使用できます。このより長いサイクルは、ビルドをテスト サーバーにデプロイし、自動化された機能テストを実行し、「遅すぎる」、「まだ速くない」、または必要な他のことを実行することで構成されます。組織によっては、展開可能なパッケージ (ドキュメントなど) に追加したり、クライアントに表示されるものなどに応じてリリースの名前を変更したりできます。ここで渡されたビルドは、すぐに使用できる可能性があります。
実行するパフォーマンス テストもある場合は、2 番目のサイクルのビルドを入力として使用する 3 番目のサイクルが必要になる場合があります。
これは簡単に説明しますが、ここでの主なポイントは、物事を分離することです。そのため、1 つのサイクルよりも迅速にフィードバックを取得しながら、すべてを連鎖させることができます。これは、スピード (フィードバック) の利点と、物事を行うための自然な場所を得ることができるため、良いアプローチだと思います。
最後に、特に CI を後付けする場合は、これを行う方法もプロジェクトごとに異なることに言及したいと思います。ビルドと単体テストのみを含む別の継続的なビルドを作成し、リリースとテストにフィードする 1 日 1 回 (または何か) のビルドを作成することもできます。これはもちろん、開発のみが高速 CI ビルドを使用することを意味します。高速 CI ビルドは不完全であり、展開には適していないためです。それでも、長期的には、これはあなたが望む場所ではありません。チェーン全体を自動化したい。
何年にもわたって、私はこれをさまざまな方法で行ってきました。1 つ目は、デバッグ ビルドの「サニティ テスト」に合格した場合にのみ、リリース ビルドが行われるということでした。また、ユーザー主導の検証のために、運用前の環境に自動展開されます。
私はまた、リリース ビルドがほとんど神聖なものとして扱われ、「実際に展開する準備をする時」と見なされたときにのみ作成される場合に、これが行われるのを見てきました。それに伴い、いくつかの「事務処理」と承認が行われ、リリース ビルドが (手動で) 作成され、サニティ チェックとデプロイが行われます。
私の経験から言えば、一貫性があり、会社やチームが理解している方法で機能している限り、それは問題ではありません。粒度に逆らうのは最初は簡単ですが、あるクライアントで実際に構造化されたビルド/展開アプローチをすべて放棄したという結果になります (1 億ドルの企業がそれをやったと想像してみてください。しかし実際に彼らはそうしました)。