monorepoを複数のチームに分割して、それぞれがリポジトリのスライスのみにアクセスできるようにする方法は？
Monorepoには多くの利点があります。また、GoogleやFacebookなどの大企業がこの技術を使用して、すべてのソースコードを単一のリポジトリに保持していることも確認しました。
しかし、monorepoを使用する場合、特定のチームのアクセスを、彼らが取り組んでいるプロジェクトに制限するにはどうすればよいでしょうか。
たとえば、マイクロサービスインフラストラクチャがあります。
- サービスA
- サービスB
- APIゲートウェイ
サービスAはチームAを使用して開発され、サービスBはチームBによって開発されますが、このプロジェクトではApi Gatewayが一般的なリポジトリです。
各チームのアクセスを独自のサービスのみに制限するにはどうすればよいですか？
現在、すべての部分を独自のリポジトリに保持しており、この方法で各チームのアクセスを制御できます。しかし、これをmonorepoに移行するように頼まれました。ソースコードを保護し、そのようなアプローチでプロジェクトを分割する方法がわかりません。
したくない
Monorepoの要点は、すべての開発者canがすべてのコードに触れることです。これにより、すべてのプロジェクト、サブプロジェクト、およびライブラリをコードベース全体で「同期」させることができるため、「バージョン依存関係の地獄」などに陥ることがありません。
例：
チームService-Bは、monorepoの共通ライブラリでいくつかの再構築を行う必要があります。これにより、API-GatewayおよびService-Bのコードが壊れます。
チームBは、AとAPIのコードの修正やallテストスイートの実行を確認するなど、再構築プロセス全体を行います。 （チームB will他のチームに最初に確認する可能性があります。もちろん、毛むくじゃらの場合、他のチームからいくつかのサポートを受けることがあります。）
すべてのテストスイートが実行され、すべてが正常な状態になると、チームBは、monorepoの新しい唯一の状態をチェックインします。
免責事項：私たちは一種のmonorepoを持っています。それが成長し続けているので、一部の人々が考えているように思われるすべての幸福な道であると私は確信していません。特に重いツールと優れたテストスイートがないと、すぐに壊れやすくなります。
Googleのタイタスウィンタース 一部説明ありCppCon 2017：Titus Winters“ C++ as a "Live at Head" Language "。 （少なくとも、彼がモノレポのアプローチを説明したのはこのビデオだったと思います。）
変更されたファイルに基づいて特定の人からのレビューを要求するシステムを検討します。
たとえば、/service-aに関連するコードは、そのサービスを主に担当するチームのメンバーによるレビューが必要です。このようにして、サービスAチームの外部のエンジニアは、サービスAのソースコードを操作できますが、そのチームの承認なしにマージすることはできません。