Monorepo
MonorepoかMultirepoか? という検討課題。特にMicroservicesでは議論の的になるようだ。
メルカリShopsのMonorepo事例
Pros
プルリクが1ヶ所に統合できる
Cons
コードオーナシップが低下する?
Quipperの事例
CircleCIの見解
Pros
見やすい
コードを共有できる
コラボレーションがしやすい
標準化が容易
状況を把握しやすい
リリースを管理しやすい
リファクタリングが容易
Cons
「色々デメリット考えられるけど、ちゃんと考えてプロセス設計すれば大丈夫よ」という見解。
Microservices 2nd Editionでの見解
Multirepo
マイクロサービスごとに1つのリポジトリを用意するアプローチは、チームの規模によらず上手く行かせることはできる。だが、マイクロサービスの境界を越えて多くの変更を加えのであれば、Monorepoパターンの方が適しているかもしれない。また、コードの再利用は、コードがパッケージングされていることを前提とするので、Monorepoよりも複雑になりうる。
Monorepo
超大規模組織で、Monorepoアプローチがとてもうまく機能しているところもある。GoogleとMicrosoftはもとより、Facebook、Twitter、Uberも一つだ。これらの組織に共通していえるのは、技術に特化した大企業であり、このパターンを最大限に活用するために多大なリソースを割くことができることだ。
一方で、開発者やチームの数が少ない場合もMonorepoが上手く機能するようだ。10人から20人程度の開発者であれば、Monorepoで所有権の境界を管理し、ビルドプロセスをシンプルに保つことは簡単だ。新しいツールや作業方法を必要とする問題に直面し始める規模でありながら、そこに投資する余力はない、という中間規模の組織だと、ペインポイントが浮上してくるようだ。