継続的統合：どの頻度？
私は常に各コミット後にビルドを起動してきましたが、この新しいプロジェクトでは、アーキテクトから頻度を「15分ごとに1つのビルド」に変更するように依頼されただけで、なぜそれが正当な理由であるのか理解できません。コミットごとに構築する」。
まず、いくつかの詳細：
- Objective-C（iOS 5）プロジェクト
- 10人の開発者
- 各ビルドには実際に1分ほどかかり、ビルドと単体テストが含まれます。
- 統合サーバーはMac Miniなので、ここでは計算能力はそれほど問題ではありません
- xCodeプラグインでJenkinsを使用します
私の主張は、コミットごとにビルドすれば、今何が問題になっているかを確認し、他の開発者をあまり気にせずにエラーを直接修正できるというものでした。加えて、私たちのテスターはUTエラーによってこの方法で悩まされることが少なくなります。彼の主張は、開発者が「ビルドエラー」メールによって溢れるだろうということでした（Jenkinsは、最初の壊れたビルドのみをメールで送信します）。ビルドの頻度が高すぎると、その指標を適切に実行できません。
それで、これについてあなたの意見は何ですか？
フェイルファストは良い原則です-ビルドが壊れていることを早く知れば知るほど、問題のコミットをより早く識別してビルドを修正できます。
すべてのコミットで構築することは正しいことです。
プロジェクトがそのような時間枠内に大量のコミットを持っている場合、15分ごとのビルドは無意味になる可能性があります-不良コミットの追跡には時間がかかり、判別が難しい場合があります（複数）の状況にある場合もありますコミットはビルドを壊すさまざまなことを持っています）。変更が加えられていないにもかかわらず、静かな時間（夜間？）に再構築される可能性もあります。
ビルドが頻繁に中断して問題になる場合は、ビルドを中断しないことの重要性と、これが起こらないことを保証する手法（頻繁なフェッチ、チェックインダンス、コンパイル、ユニットテストの実行）をチームに再教育するための回答ローカルなど...）。
何も変更がなければ、15分ごとにビルドを実行しても、文字通り意味がありません。しかし、同様に、不利な点はありません。afaik、ジェンキンスは失敗した場合にのみ電子メールを送信し、成功した場合に電子メールを送信します。
すべてのコミットでそれを行います。ただし、15分ごとにリポジトリをポーリングし、変更を確認します。おそらくそれは、同僚が言及していることです。
あなたはあなたの10人の開発者が15分に1回以上コミットすることを期待していますか？それはかなり高い見積もりのように聞こえます。 10 devとは、150分ごとに同じ人が再びコミットすることを意味します。つまり、2.5時間です。したがって、平均的な日に、各開発者が3回コミットします。個人的に私は1回のコミットを行います〜2日...時にはより多くの場合より少ない。
15分ごとの場合は、開発者にメールmoreが殺到します。これは、誰がビルドを壊して、より多くの人にメールを送るかがわからないからです。
メトリックについては、それが本当に問題である場合-問題があると思うメトリックがわからないのでわかりません-いつでも別のジョブを実行してメトリックを収集できます。
おそらく、要件は「ビルド最大で 15分に1回」になるはずです。これは、非常に頻繁なコミットアクティビティ（つまり、数分以内に複数のコミット）があり、ビルド時間が長いプロジェクトに意味があります。もちろん、ビルドの使用方法にも依存します。テスターにとって、15分以内に複数のビルドを取得するのはやや混乱するかもしれません...
しかし、何も変更がなければ、構築しても意味がありません。
一部の開発者は、1つの機能変更に属するファイルが1つのアトミックプロシージャでコミットされない方法でコミットを実行できるようにしたいと考えています。いくつかの「物理的なコミット」で構成される「論理的なコミット」を実行するには、2〜3分かかります。これは通常、開発者がDVCSを使用せずに中央リポジトリに直接コミットする場合です。
この場合、CIサーバーが最後のコミットからしばらく待ってから新しいビルドを開始することをお勧めします。ただし、15分は非常に高い数値のようです。5分以下で十分です。
または、より良い（！）、開発者が少しずつ、一度に1つだけ作業するように導いて、「機能的に完全な」物理コミットのみを実行することをはるかに簡単にします。その後、すべてのコミット後のビルドは問題なく動作します。
Jenkinsでプロジェクトまたはその依存関係へのソース管理コミットを構築するように設定している場合でも、最初にソース管理にコミットせずに開発者がアーティファクトリポジトリにデプロイすることを妨げるものではありません。調整されていないAPIの変更やアーティファクトリポジトリへの依存関係のバグをデプロイすると、Jenkinsジョブをトリガーせずにビルドが中断する可能性があります。私は個人的にこのことをできるだけ早く知りたいと思います。
理想的には、すべてのコミットをビルドし、スケジュールに基づいて、今説明したような状況をチェックします。これは概念的には、あなたが少なくとも15分に1回ビルドするを意味します。
Jenkinsジョブが依存関係アーティファクトのデプロイで実行するように設定されている場合（そうする場合... Bravo）、ユニットテストがしっかりしている（依存関係がテストされないことを意味する）場合、スケジュールされたビルドを予測できます。統合/機能テストはJenkinsの仕事の一部ではありません。
「メールの洪水」問題に関して言えば、ビルドが壊れたときにメールが殺到するのは良いことだと私は言います。開発者に説明を添えて電子メールに返信するように強制してください。そうすれば、壊れたビルドがかなり下がっていることを確認できます。信頼してください。
あなたは彼らの推論を理解できないと言ったので、あなたは彼らに尋ねなければなりません。彼らが何を望んでいるかを推測してそれを実装しようとするだけでなく、なぜ彼らがそれを要求したのか理解せずに、彼らが要求したものを実装しないでください。
とはいえ、一般的な質問に答えるには、使用する開発哲学に依存します。すべてのコミットが機能すると予想される場合は、すべてのコミットをテストする必要があります。すべてのPushが機能するという哲学でDVCSを使用する場合は、すべてのプッシュをテストします。
一般的に、知らないことを伝えてから、知っていることを繰り返すのがよいでしょう。たとえば、受信する冗長なメールの数を減らしたい場合は、ビルドの頻度ではなく、メールの設定を微調整します。