非常に大規模なプロジェクト/チームの継続的な統合はどのように拡張できますか？

従来、CIシステムは、統合ブランチ内のコードの品質のみを監視し、回帰が発生したときに通知します。修理には人間の介入が必要です。

同じブランチで作業する開発者の数が増えると、破損/閉塞のリスクが高まります。最終的には、破損が修正されるまでに平均して新しい破損が現れるポイントに到達します。ブランチの進行は実質的に無視できます。

後でマージされる別々の統合ブランチでそれぞれ作業する複数のチームに分割することは役立つかもしれませんが、関連するチャーン/ノイズ/技術部門を追加しながら、必要な統合を後で遅らせるだけなので、プロジェクトの期間を大幅に延長します個々のブランチのマージによる部分的な統合。また、各ブランチのCIセットアップ、それぞれ独自のビルド/ QAリソースなどにより、コストも増加します。また、全体的な品質が必ずしも向上するとは限りません。

スケーラビリティは、せいぜい、疑わしいものです。

このような大規模なプロジェクトを実際にスケーリングする方法はありますか？

はい、しかしそれはあなたの質問であなたが言及することを可能な限り防ぐことによってです。物事が手に負えなくなる前に同じコードで作業できる開発者は非常に少ないというのはあなたの言う通りです。すべての変更の概要があり、統合が正常に機能し、リグレッションが発生しないことを確認する人または何かが必要です。すべてが1つのリポジトリで発生する場合、これをスケーリングするのは困難です。

作業を開始する前に、後で簡単に、またはほとんど作業せずに物事を統合できるように、機能を分離する必要があります。つまり、機能を独立した部分に分割するか、少なくとも依存関係をできるだけ少なくする必要があります。これをどのように行うかは、開発している製品に大きく依存します。以前は、機能の分離は、さまざまなライブラリを作成することで行われていました。これの欠点は、これらのライブラリを管理するための優れた方法が必要になることです。たとえば、古いバージョンのWindowsには悪質なライブラリ管理システムがあり、悪名高いDLL地獄を引き起こしていました。現在、これを行うための一般的な方法がマイクロサービスです（これになりつつあります）。ただし、これには欠点もあります（通信のオーバーヘッド、監視するサービスが増えるなど）。

機能に基づく分離が困難な場合、別の選択肢として、開発を時間的に分離することができます。複数のチームが多くの異なる機能を同時に処理するのではなく、一度に1つまたはいくつかの機能のみを処理する1つのチームがあります。

作業の分離が不可能な場合は、物事を調整するためのツールとテストが必要になります。自動化された単体テストと統合テストは、ここでは大きな助けになりますが、最終的には、プロジェクトまたはチームが実行可能となる大きさには制限があります。

同じブランチで作業する開発者の数が増えると、破損/閉塞のリスクが高まります。最終的に、破損が修正されるまでに平均して新しい破損が現れるポイントに到達します

文の最初の部分はおそらく統計的に正しいのですが、2番目の部分には同意しません。

CIと統合ブランチはGIGO（ガベージインガベージアウト）を無効にすることはできません。開発者に規律がない場合、停止したブランチになりますが、統合ブランチテストは最初のバリアではなく、遅延バリアとしてのみ機能します。

開発者は、適切なコーディング標準、コードレビュー、ローカルユニットテスト、および場合によっては統合前ブランチテストを使用して、衝突の可能性を低くする必要があります。

私は何百人もの貢献者がいるこのようなシステムに毎日取り組んでいますが、驚くべきことに、ハングするのを目にすることはまれです。

十分なデータはありませんが、コストが高いのは本当かもしれませんが、一方で、統合の遅れやバグの代替コストを判断するのは困難です。

別のアプローチは、従来とは異なる別のCIシステムに切り替えることです。これは、ブランチの開発がブロックされている間、回帰を検出して回復を待つのではなく、問題のある候補の変更をコミット前に識別して拒否することで、回帰を防止できます。私はそのようなシステムをノンブロッキングCIシステムと呼んでいます。

ブランチのリグレッションを減らすために、開発者が実行したコミット前の検証要件を引き上げるだけでは、そのような保証には不十分です。それは実際に回帰率の増加を引き起こす可能性があります：より長い検証時間=>単独で同時に検証されるより多くの変更（したがって、お互いを考慮しない）=>機能の競合および干渉のより高いリスク。これについては、「コミット前の検証カバレッジを拡張するとブランチの安定性の神話が増えるはずです」でもう少し詳しく説明します。

もちろん、CIツールは大規模に動作できる必要もあります。そして、そのようなツールが存在します。ブランチの品質レベルの低下を保証しないCIツールはありますか？を参照してください。

^{情報開示：私は上記のリンクに記載されている会社の関連会社です。}