大企業では継続的インテグレーションはどのように組織されていますか？

私の会社では、各機能/バグ修正ブランチがdevでどのようにマージされるかを確認するために中間ビルドを行わないのが一般的です。毎日のビルドのみがあり、常に多くのテストの失敗とビルドエラーが発生します。私は、1000人以上の開発者がマージごとにビルドするのは理不尽だと言われています。

それで、私はCIがそれ以上の開発者（Microsoft、Facebook）を持っている会社でどのように組織されているかを検索しましたが、何も見つかりませんでした。たぶん、インサイダーは私に言うことができますか？

基本的に、スケーリングの問題です。作業をモジュールに分割します。モジュールは、プロジェクトや製品の機能が異なる場合があります。

これらのモジュールのセットをカバーするチームがあります。これらの各チームは、それぞれのスコープにCIサイクルを設定し、それぞれのサイクルが経過した後にのみ、コードがマスターリポジトリにプッシュされ、そこでマスターCIサイクルが実行されます。

マスターCIサイクルは、次の点でおそらくチームレベルのCIサイクルと異なります。

• チームレベルのCIサイクルでは、会社全体のコードをビルドする必要はなく、担当するモジュールと依存モジュールのみをビルドする必要があります。完全に独立しており、異なるチームにある2つのモジュールがある場合、それらは他のチームのCIサイクルの一部ではありません。
• チームレベルのCIサイクルでは、マスターCIサイクルよりもはるかに詳細な自動テストを実行できます。マスターCIサイクルには、マスターソリューションのサイズに応じて、これらのテストの実行に24時間以上かかることがあるため、健全性チェックテストと回帰テストが毎日行われます。

このアプローチで行う必要があるのは、開発者がコードをセントラルリポジトリにプッシュするのに膨大な時間を費やさないように、ローカルCIサイクルが過ぎたら、ローカルリポジトリからセントラルリポジトリに自動プッシュを提供することです。

@Vladimir_Stokicが言ったことに加えて、一部のチーム（私の開発者は150人まで）では、24時間ごとよりも頻繁にビルドを行います。コミットが発生するたびに、5分間のタイマーを開始します。5分間が経過すると、5分間に発生したすべてのコミットが結合され、ビルドされます。ビルドは通常、増分ビルドです。発生するビルドごとに単体テストを実行する個別のビルダーがあります。ビルドが完了した後、ビルド中にさらにコミットがあった場合（変更内容に応じて1〜45分かかります）、保留中の変更がビルドされます。夜間（クリーン、フル）ビルドもありますが、各コミットで発生するビルドは（大まかに）テストが失敗したかどうかを非常にすばやく知らせます。