継続的インテグレーション：どの周波数ですか？

私は常に各コミットの後にビルドを開始しましたが、この新しいプロジェクトでは、アーキテクトは「15分ごとに1つのビルド」に頻度を変更するように頼みました。コミットごとに構築する」。

まず、いくつかの詳細：

• Objective-C（iOS 5）プロジェクト
• 10人の開発者
• 各ビルドには実際に約1分かかり、ビルドと単体テストが含まれます。
• 統合サーバーはMac Miniであるため、ここでは計算能力は実際には問題になりません。
  • JenkinsとXCodeプラグインを使用します

私の主張は、コミットするたびにビルドすれば、他の開発者を頻繁に煩わせることなく、今何が間違っているかをすぐに確認し、エラーを直接修正できるということです。さらに、この方法でテスターはUTエラーに悩まされることが少なくなります。彼の主張は、開発者は「ビルドエラー」メール（最初の壊れたビルドのみにメールを送信するように構成できるため、完全に真実ではない）であふれ、頻度が適切な場合にメトリックを実行できないというものでしたビルドの数が多すぎます。

だから、これについてあなたの意見は何ですか？

フェイルファーストは良い原則です-ビルドが壊れていることが早くわかるほど、問題のあるコミットを特定し、ビルドを修正できます。

コミットごとにビルドすることは正しいことです。

このような時間枠内でプロジェクトに大量のコミットがある場合、15分ごとにビルドすることは無意味です-悪いコミットを追跡するのに時間がかかり、判断が難しい場合があります（複数のコミットが異なることを行う状況もあります）ビルドを壊します）。また、静かな時間（夜間ですか？）に変更が加えられていなくても、再構築する可能性があります。

ビルドが頻繁に壊れて問題になる場合は、ビルドを壊さないことの重要性と、これが発生しないことを保証する手法（頻繁なフェッチ、チェックインダンス、コンパイルおよび単体テストの実行）をチームに再教育するために回答しますローカルなど...）。

何も変更がなければ、文字通り15分ごとにビルドを実行しても意味がありません。しかし、同様にマイナス面もありません。ジェンキンスは失敗した場合にのみメールを送信し、成功した場合にのみメールを送信します（例：10が失敗した場合）。

すべてのコミットでそれを行います。ただし、リポジトリを15分ごとにポーリングし、変更を確認します。これは、おそらく同僚が言及していることです。

10人の開発者が15分ごとに複数回コミットすることを期待していますか？それはかなり高い見積もりの​​ように聞こえます。10人の開発者は、150分ごとに同じ人が再びコミットするので、2.5時間になることを意味します。したがって、平均的な日に、各開発者は3回コミットします。個人的に私は1つのコミットを行う〜2日...時にはもっと少ない。

これは、メールでの洪水の開発者に起こっているのより多くのそれは15分ごとにのみだ場合。それは、ビルドを壊した人を特定できないため、より多くの人にメールを送信するからです。

メトリックについては、それが本当に問題である場合（どのメトリックに問題があると思われるかわからないため）、メトリックを収集するための別の仕事をいつでも行うことができます。

おそらく、要件は「せいぜい 15分ごとに1回ビルドする」ことでしょう。これは、非常に頻繁なコミットアクティビティ（数分以内に複数のコミット）があり、おそらくビルド時間が長いプロジェクトにとって意味があります。もちろん、ビルドの使用方法にも依存します。テスターに​​とって、15分以内に複数のビルドを取得するのはやや混乱するかもしれません...

しかし、何も変わっていなければ、構築しても意味がありません。

一部の開発者は、1つの機能変更に属するファイルが1つの単一のアトミックプロシージャでコミットされない方法でコミットを実行できるようにしたいと考えています。「物理的なコミット」で構成される「論理的なコミット」を行うには、2〜3分かかります。これは通常、開発者がDVCSを使用せずに中央リポジトリに直接コミットする場合です。

この場合、最後のコミット後、新しいビルドを開始する前にCIサーバーをしばらく待機させることをお勧めします。ただし、15分は非常に高い数値のようで、5分以下で十分です。

または、より良い（！）、開発者が小さな部分のみで動作するようにガイドし、一度に1つのことだけを行うようにして、「機能的に完全な」物理コミットのみを実行することをはるかに容易にします。その後、すべてのコミット後のビルドは見かけ上動作します。

Jenkinsがプロジェクトまたはその依存関係のソース管理コミットをビルドするように設定している場合でも、開発者が最初にソース管理にコミットせずにアーティファクトリポジトリにデプロイすることを妨げません。調整されていないAPIの変更またはアーティファクトリポジトリへの依存関係のバグを展開すると、Jenkinsジョブをトリガーせずにビルドが破損する可能性があります。私は個人的にこの至急について知りたいと思います。

理想的には、コミットごとにビルドし、また、先ほど説明したような状況をチェックするスケジュールでビルドすることもできます。これは概念的に、少なくとも15分に1回ビルドすることを意味します。

依存関係アーティファクトデプロイで実行するようにJenkinsジョブを設定している場合（および... Bravoを実行している場合）、単体テストが安定している（依存関係をテストしないことを意味する）場合、スケジュールされたビルドを調査できます統合/機能テストはJenkinsの仕事の一部ではありません。

「電子メールであふれる」問題に関しては、壊れたビルドで電子メールがあふれることは良いことだと思います。開発者にメールで説明を返信するように強制すると、壊れたビルドが完全にダウンするのがわかります。信頼してください。

あなたは彼らの推論を理解できないと言ったので、彼らに尋ねなければなりません。彼らが何を望んでいるかを推測してそれを実装しようとしないでください。そして、彼らがそれをなぜ求めたのか理解せずに彼らが求めたものを単に実装しないでください。

ただし、一般的な質問に答えるには、使用する開発哲学に依存します。すべてのコミットが機能すると予想される場合、すべてのコミットをテストする必要があります。すべてのプッシュが機能するという哲学でDVCSを使用する場合は、すべてのプッシュをテストします。

一般に、知らないことを伝えてから、知っていることを繰り返すのがよいでしょう。たとえば、受信する冗長な電子メールの数を減らしたい場合は、ビルド頻度ではなく、電子メール設定を微調整します。