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で所有権の境界を管理し、ビルドプロセスをシンプルに保つことは簡単だ。新しいツールや作業方法を必要とする問題に直面し始める規模でありながら、そこに投資する余力はない、という中間規模の組織だと、ペインポイントが浮上してくるようだ。