2
私が「時間」と言うとき、私はビルド（コンパイル、ユニットテスト、コードカバレッジ、静的解析など）で起こっているすべてを含めています急速に発展するためにサーバー時間を構築することの重要性は？
私は何を得ているかは、ハードウェアをアップグレードするか、より小さなビルドに分割する必要があります。
現在、私は5分に向かって傾いています。
A
答えて
3
5分が良い出発点です。私は、6人のチームで構築するのに12-15分かかったプロジェクトを持っていました。私たちのルールは、ビルドプロジェクトやあなたが壊れていない壊れたビルドにコミットすることではありませんでした。コミットは12-15分ごとにしか起こらず、これが問題になりました。より良いハードウェアに投資し、1）ビルドと単体テスト、2）受入れテストとコード品質チェックにビルドを分割しました。私たちはステップ1の後にもう5分から6分ほどかかるコミットを許可するようにルールを修正しました。
考慮すべきもう1つの要素は、コミット後すぐにあなたの職場環境を昼食、会議、またはその日のままにすることです。私は午後6時にコミットし、6時20分まで待つことを覚えています。朝まで私が待つ時間があった。
だから、2つの要因がある：
- どのくらいコミット間の？
- 開発者がコミットしないようにビルド時間が長すぎますか？
1
リポジトリを使用可能な状態に戻すために複数のコミットが必要な場合は、ビルドが「中断しない」ように、継続的インテグレーションサーバ（Hudson）に実際に明示的な遅延が設定されています1分の間に複数のコミット）。たとえば、相互に依存する複数のプロジェクトがあり、それぞれがコミットする必要があります。また、変更が論理的に独立しているため、別々にコミットする必要があるコードを持つこともできます。
連続的な統合の主な目的の1つは、何も誤って壊れないようにすることです。特に、何かが壊れても、できるだけ早く誰かが見つかるようにしてください。問題が作成された時点に近い時点で問題を修正することは、開発者が最終的にビルドを行うときよりもずっと早く簡単に行うことができます。
さらに、継続的な統合（ビルド）システムの単なる存在は、開発者を最良の行動に保つ傾向があります。
あなたのビルドが数時間かかることがない限り、それはおそらく大丈夫です。