ビルドを高速化するための考慮事項:
ビルドは I/O バウンドになる傾向があるため、I/O を複数のドライブ/コントローラーまたはマシンに分散させます。たとえば、ソースを 1 つの物理ドライブに置き、ターゲット (ビルド出力) を別の物理ドライブに置き、ビルド ツール (.NET、Java、Ant など) を含む物理ドライブからこれらのドライブを分離します。 ) および OS を含む物理ドライブから。
多くの場合、ビルドは非同期で実行できるため、個別のビルド マシン (継続的インテグレーション サーバー) を確立して使用します。これは特に、メトリクスの計算、ドキュメントの生成、リリース候補の生成、および開発者のワークステーションで時間がかかりすぎる、または必要のないその他すべての場合に使用します。
多くの場合、ビルド ツールには多くのプロセスの起動/シャットダウン オーバーヘッドが伴うため、そのオーバーヘッドを最小限に抑えるツール、スクリプト、および手順を選択してください。これは、他のツールをサブプロセスとして呼び出す傾向がある make や Ant などのツールに特に当てはまります。たとえば、私は Python ベースのビルド システムに移行して、ほとんどのビルド処理を 1 つのプロセスから実行できるようにしながら、必要に応じて他のプロセスを簡単に生成できるようにしています。
ビルド ツールは、多くの場合、何もしないことを検出してビルド ステップをスキップすることをサポートしています (最後のコンパイルからソースが変更されていないため、コンパイルしないでください)。ただし、ビルド ステップをスキップするためのサポートは、多くの場合、デフォルトではアクティブになっていません。具体的に呼び出す必要がある場合があります。たとえば、コンパイラは通常これを自動的に行いますが、コード生成は行いません。もちろん、これに対する当然の帰結は、可能な場合はインクリメンタル ビルドを使用することです (ワークステーションでの開発中は、「動作する」限り)。
ビルド スクリプトはすぐに非常に複雑になる可能性があるため、時間をかけて単純化してください。最初に、ビルドを個別のプロジェクトに分割し、それぞれが JAR、DLL、または EXE などの「アーティファクト」を 1 つだけビルドします。これにより、現時点では必要のない長いビルドを呼び出さないようにするだけで、多くの時間を節約できます。第二に、別のプロジェクトに到達しないことで、すべてのプロジェクトのビルドを単純化します。ソースではなく、ビルド アーティファクトを介して常にプロジェクトの依存関係を作成します。これにより、各プロジェクトがスタンドアロンになり、「スーパー」スクリプトを使用してプロジェクトのさまざまなサブセットを自由に構築できます。
最後に、ビルド インフラストラクチャを独自の実際のプロジェクトとして扱います。バグや機能のリクエストをログに記録し、バージョンを管理し、公式リリースを実行し、無期限に改良を続けます。後付けとしてではなく、不可欠な製品として扱います。ビルドは、健全なプロジェクトの生命線です。気にかければ、パンを節約できます。