実際の継続的なビルドに比べて、毎日のビルドにはどのような利点がありますか？
私はこの質問を見て、これが重複しているとは思いません 毎日のビルドと継続的な統合に適切なソフトウェアモデルは何ですか？ 。
私は、自動デイリーコンプリートビルドが実際にすべてのコミットを構築することに対してどのような利点があるかを完全に理解していません（私が信じている用語は継続的な統合です）。企業は、毎日のビルドについて尋ねられたときに、すべてのコミットでビルドすることを言及しているとよく耳にします。
以下のジョエルによる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に提供され、テストが実行されます。
- 日中、ソフトウェアを作成しているときに、その日の最初のコミットがビルドを開始します。その後、コミットがキューに入れられ、前のビルドが完了すると、間に発生したすべてのコミットで次のビルドが開始されます。実際には2つの連続ビルドを行います。新しいコミットで変更されたもののみをビルドする迅速なインクリメンタルビルドと、ゼロからの別のフルビルド。フルユニットテストでは、フルビルドに最大90分かかります。インクリメンタルビルドはビルドに数分しかかからず、迅速なターンアラウンドのために少数のユニットテストを実行すると思います。ビルドまたはテストが失敗した場合、前回の成功したビルドと現在のビルドの間のコミットの1つが原因であることがわかります。これにより、どのコミットが問題をかなりうまく引き起こしたかが絞り込まれます。 5-8のコミットのどれであるかを見つけるために、少し探偵の仕事をしなければならないかもしれませんが、開発者は通常同じ領域で働いていないので、通常はかなり明白です。
QAが夜間ビルドの問題を見つけたら、その日にビルドした継続的ビルドに戻り、問題が特定のビルドにあることを理解できます。 （つまり、ビルドを後退させて、それがどこで発生したかを確認します。）そのビルドに含まれていたコミットを確認し、必要に応じて正確なものに絞り込み、コミットを元に戻すか、問題を修正します。
以前は似たような見方をしていた。今、私はコミットごとのビルドに加えて毎日のビルドがあるべきだと思います。
- 追加のタスク：コミットごとのビルドでは不要な追加のタスクをcronビルドに追加できます。たとえば、cronビルドは依存関係をスキャンしてアップグレードを確認し、それらに関するプルリクエストを自動的に作成できます。
- 健全性：何らかの理由でcronビルドが失敗した場合（そうではないはずですが、失敗する可能性があります）、その後のコミットごとのビルドが同じ理由で失敗すると予想するのは当然です。コードの変更がどのようにビルドを壊すかを理解するのではなく、根本的な問題を解決してください。
- ステータスミーティング：10:00にステータスミーティングがある場合、9：00にcronビルドが必要です。成功するはずですが、何らかの理由で成功しない場合は、ビルドの修正がステータスに含まれるはずです。
- コスト：おそらく必要ではありませんが、いくらかかりますか。メリットは最小限のコストを正当化すると思います。
Cronビルドは、コミットごとのビルドの補足であり、置き換えとは見なされません。
実行するのに十分なリソースがある限り、毎日（または他の定期的な）ビルドを実行する利点はありません同じコミットごとにビルド。
定期的なビルドは、そのようなリソースが十分にない場合の妥協策です。以前の正常なビルド以降に複数の新しいコミットを取得した後にそのようなビルドが失敗した場合、実行する必要があるため、障害のあるコミットをすぐに特定する機能を放棄します。欠陥のあるものを正確に特定し、問題を修正するための追加作業。そして、それは常に単純であるとは限りません。たとえば、あらゆる種類の potential 複雑化の余地があります。次に例を示します。
- 新しいビルドで複数の障害のあるチェンジセットが同時に検出され、識別がより困難になります
- 障害のあるチェンジセットの上にコミットされた後続のチェンジセットが原因で、障害のあるチェンジセットのクリーンバックアウト/リバートができない可能性があります。修正は既知の良好なリポジトリ状態にバックトラックしませんが、良好な場合とそうでない場合がある新しい状態に移動します。 、確認のために1つ以上の追加ビルドが必要
- 障害のあるチェンジセットをクリーンバックアウトしても、バックアウトされたチェンジセットまたは障害のあるチェンジセットによっては、後続のチェンジセットが原因で適切なビルドにつながらない可能性があります
個人的に私は、事前コミット/ゲーティング検証を行うCIシステムを支持します。特に大規模プロジェクトでは、チーム全体の作業に影響を与えた後でそれらを検出して修正するよりも、障害のあるチェンジセットがリポジトリに到達することさえありません。プロジェクトで。
使用されるオーケストレーションアルゴリズムに応じて、このようなシステムは、すべての候補チェンジセットのビルドを実行するための十分なリソースがない/ がなくても、破損/回帰の100％の防止を保証できます。