私はこの質問を見て、これが重複しているとは思いません 毎日のビルドと継続的な統合に適切なソフトウェアモデルは何ですか? 。
私は、自動デイリーコンプリートビルドが実際にすべてのコミットを構築することに対してどのような利点があるかを完全に理解していません(私が信じている用語は継続的な統合です)。企業は、毎日のビルドについて尋ねられたときに、すべてのコミットでビルドすることを言及しているとよく耳にします。
以下のジョエルによる2番目の記事は、「継続的なビルドを実行するのは魅力的ですが、後で説明するソース管理の問題のため、おそらく実行できないのです。」と述べていますが、検索しても、完全にはわかりません。
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/
https://www.joelonsoftware.com/2001/01/27/daily-builds-are-your-friend/
これらの2つの記事では、継続的な統合(私の理解ではすべてのコミットで構築される)とは対照的に、毎日のビルドの方がより実用的/有利であると言及されています。
しかし、それは私にはまだはっきりしていません。私は現在、おそらく2つの特定の例しか考えていません
1)多くの(git)プッシュ/マージが常に行われ、フルビルドを実行するのに十分なビルド時間が必要です。
完全なビルドに関するJoelの説明は次のとおりです。「完全–可能性はあります。コードには複数のバージョンがあります。複数の言語バージョン、複数のオペレーティングシステム、またはハイエンド/ローエンドバージョンです。毎日のビルドでは、すべてをビルドする必要があります。 。そして、コンパイラーの不完全な可能性がある増分再構築機能に依存せずに、すべてのファイルを最初から構築する必要があります。
おそらく、リソースを節約できますが、1日の真ん中に1回のフルビルドを実行するだけで、関連するすべての迅速なユニット/統合テストをすべてのプッシュで実行することで落ち着きます。
おそらく完全なビルドがノンストップである一定のキューは、ビルドが常に遅れているためか、ビルドの関連性と目的を無効にする十分に大きなキューを作成する可能性があります。
これは、理想的にはおそらくすべてのプッシュで完全なビルドになりますが、実際には、プッシュのスループットを処理できるハードウェアはありません。
2)プッシュごとのビルドではなく、毎日のビルドをスイープする方が便利な場合があります(彼の毎日のビルドの理由5は、あなたの友人の記事です)。
私は数十人のソフトウェアエンジニア、数十人のQAエンジニアなどと一緒に非常に大規模なプロジェクトに取り組んでいます。コードベースは数百万行のコードです。私たちは毎晩ビルドを行っており、継続的なビルドを行っています。それらは異なる目的を果たします:
QAが夜間ビルドの問題を見つけたら、その日にビルドした継続的ビルドに戻り、問題が特定のビルドにあることを理解できます。 (つまり、ビルドを後退させて、それがどこで発生したかを確認します。)そのビルドに含まれていたコミットを確認し、必要に応じて正確なものに絞り込み、コミットを元に戻すか、問題を修正します。
以前は似たような見方をしていた。今、私はコミットごとのビルドに加えて毎日のビルドがあるべきだと思います。
Cronビルドは、コミットごとのビルドの補足であり、置き換えとは見なされません。
実行するのに十分なリソースがある限り、毎日(または他の定期的な)ビルドを実行する利点はありません同じコミットごとにビルド。
定期的なビルドは、そのようなリソースが十分にない場合の妥協策です。以前の正常なビルド以降に複数の新しいコミットを取得した後にそのようなビルドが失敗した場合、実行する必要があるため、障害のあるコミットをすぐに特定する機能を放棄します。欠陥のあるものを正確に特定し、問題を修正するための追加作業。そして、それは常に単純であるとは限りません。たとえば、あらゆる種類の potential 複雑化の余地があります。次に例を示します。
個人的に私は、事前コミット/ゲーティング検証を行うCIシステムを支持します。特に大規模プロジェクトでは、チーム全体の作業に影響を与えた後でそれらを検出して修正するよりも、障害のあるチェンジセットがリポジトリに到達することさえありません。プロジェクトで。
使用されるオーケストレーションアルゴリズムに応じて、このようなシステムは、すべての候補チェンジセットのビルドを実行するための十分なリソースがない/ がなくても、破損/回帰の100%の防止を保証できます。