これはアソビュー！ Advent Calendar 2022の23日目です。
アソビューでVPoE兼Tech Leadをしているdisc99🐼です！
今回は、Monorepo運用の事例紹介をさせてもらえればと思います！
アソビューではほぼすべてのGitリポジトリを統合したMonorepo運用を2年以上行っています。
最近では特定の技術領域やプロダクトに対してMonorepoを適用した事例は増えてきています。
しかし、社内のほぼすべてのソースコードを1つのMonorepoで管理している組織はまだ多くないと思いますので、参考になれば幸いです。
今回はなぜMonorepoに移行したかや、具体的にどのような管理をしているか、また今後の展望などを公開します！
🐣なぜMonorepoなのか
背景
もともと2020年頃まではアソビューでは、複数のリポジトリを利用するPolyrepo(Multirepo/Manyrepo)で運用を行っていました。
当時は30名程度のプロダクト組織に対して120以上のリポジトリ(アプリケーション、ライブラリ、IaC、ツール、ドキュメント等)があり、多くの開発者が存在すら知らないリポジトリが大半でした。
また、依存関係にある複数のリポジトリに対する開発も多数存在し、リポジトリ単位で環境構築や修正、PRやリポジトリ横断での結合テストなどに対する運用コストの高まりもありました。
結果、ナレッジの分散による組織全体の開発速度や柔軟性が低下し、オーナーシップやメンテナンスも曖昧になり、一部のメンバーに負荷が偏ったり、会社として担保したい統制が取れない状態が発生していました。
加えて、アソビューではフルサイクルエンジニアという考え方を重要視しており、チームやエンジニア一人一人が自分の得意領域に囚われず、開発プロセス全てに責任を持てる状態を目指す必要がありました。
詳細は、こちらの記事に記載していますので興味があれば御覧ください。
これらの課題の高まりがあり、120以上あったリポジトリを単一のMonorepoに移行を決定しました。
この移行はマネジメント業務の空き時間を使ってほぼ私1人で3ヶ月程度で完了したため、目的設定次第では多くの組織で適応ができるものと思います。
また専任の担当が付けるような環境であれば1ヶ月もかからない内容になると思います。
Monorepoとは？
複数のプロジェクト、アプリケーションやライブラリなどのソースコードを単一のリポジトリで管理する方法です。
同一のプロジェクトやプロダクト、技術に限定したり、依存関係の有無など様々なアプローチが存在しますが、本記事ではMonorepoの厳密な定義は割愛します。
最近では多くの国内企業で導入事例が紹介されており、世界的にはGoogleやMeta、Microsoft、Twitter、Uberなど大手企業でも導入されています。
特にマイクロサービスやフロントエンドなどソースコードベースが分割される設計も増加し、より需要が高まってきていると思います。
Monorepoの特徴としては以下のようなものが上げられます。
素早さ
複数のプロジェクトやアプリケーションやライブラリのソースコードに対して1コミットで変更を行うことができ、ビルドキャッシュの利用や、依存関係を意識したタスク実行、場合によっては分散キャッシュや分散タスクの実行を利用し、素早くビルドの実行を行うことができます。
分かりやすさ
複数のソースコードを横断して確認し、依存関係を管理したり、可視化したりすることが容易になります。
また、一括したメトリクスの収集などもリポジトリ内で完結させることができます。
管理のしやすさ
ソースコード共有や複数言語に対して一貫した開発体験を提供したり、プロジェクトのテンプレート化やScaffold、依存関係のコントロールなども定義しやすくなります。
その他
単一のリポジトリにまとまっているからといって、ビルドやデプロイなどが毎回実行されるわけではありません。
通常はソースコード変更や、その変更に依存するソースコードやテストのみを実行するため、リポジトリが単一になっているからといって必ず遅くなるものでも無いです。
また、リポジトリの内部的には一定のルールに従い独立管理するため、複数チームが同じリポジトリを操作することによって独立性を損なう可能性も低く、むしろ同一リポジトリにあるからこそコラボレーションも容易になります。
加えて必要時には、CODEOWNERSなどを設定することでオーナーシップを明確にすることもできます。
詳しい説明はこちらのページが参考になります。
比較対象としてはPoryrepoがあり、どのような差があるかもまとめられています。
🛣️移行の道のり
通常リポジトリには多数のファイルが含まれていますが、PolyrepoからMonorepoするだけであれば単純にファイルを移動させれば完了になります。
しかし、実際にはGitの履歴や、ビルドツールやCI/CD、各リポジトリごとの設定や仕組み(GithubのIssueや外部連携)変更、ブランチ戦略など、多数の移行対象が存在します。
アソビューでのMonorepo化の進め方
Monorepo化はプロダクト組織へ全体影響の大きい変更となるため、CTOや開発チームに対して、どのような目的で行うかやMonorepoの説明、Before/Afterでどのように変わるか、どういった優先度で行うかなどの説明会やQAを行いました。
以下は、当時説明時に挙げた目的や優先度の抜粋になります。
# 目的 - 誰でもアソビューで扱っているアプリケーション全体が確認、見ることができる状態にする - 開発速度の向上 - 1つのfeatureに対して、同一ブランチでの開発、リリースを可能にし、プロダクトとして統一されたバージョン管理を行う(確実性、安全性) - フロント、バックエンド、インフラも含め変更、管理の自動化 - 開発、運用ルールやテストなどの統合 - プロジェクト立ち上げコストの低減 - ローカルやstagingなど、開発時に必要な設定、手順の統一、自動化 - 複数プロダクトを横断したE2Eテストの導入 - プロダクト全体の開発の計測、可視化(コミット、ビルド、デプロイ、テスト、リリース履歴) # 優先度 1. 既存のリポジトリが移行しやすい(大掛かりな修正が不要)こと 2. パッケージの依存関係を定義/CIに反映できること 3. 将来的な追加、変更のコストが少ないこと このプロジェクトでは、1を最優先とします。たとえ理想的なMonorepo構成やツールが利用できない場合でも、移行の確実性を重視します。 理由として、 - 理想構成への移行は相応の時間と、修正リスクを伴う - 移行ができないリポジトリ(並行運用期間)が長くなれば長くなるほど、結果的に管理コストが増える（目的との乖離） - 移行が進んだ段階で、別フェーズとして理想構成を再検討すればよい ということを重視しているためです。
説明会やQAで出てきた、フィードバックも反映し移行を実施しました。
特にこのタイミングで重要視していたのは"優先度"にもあるスピードでした。
Polyrepoで運用されているリポジトリは、そのリポジトリ単位で個別最適が進んでいる場合があります。
一方Monorepoの場合、複数リポジトリを一括管理するための最適化やツールが存在し、場合によってはビルドツールやCI/CDを大きく変更する必要が出てきます。
こういった組織全体に影響するプロジェクトの過渡期は、新旧が入り乱れる状態になり運行コストの増加や混乱が発生しやすくなります。
また、最悪の場合途中で頓挫し、中途半端な状態でその先の運用になると、移行前より環境が悪化することもありえます。
そのため、"最良"のMonorepoを作ることより、"最速"でMonorepoに移行することを優先することとしました。
Monorepoの構成
移行するにあたって、Monorepoの構成をどうするかを検討しました。
以下が現在のMonorepo構成になっており、ルート直下にpackagesというディレクトリを作成し、Pelyrepoから移行したリポジトリはその配下に配置するようにしています。
※以降Monorepoへ移行したPolyrepoのリポジトリ(packages配下のディレクトリ)のことをパッケージと記載します
. ├── .circleci │ ├── config.yml # Circle CIの設定ファイル │ └── script # CIで利用するスクリプトを管理します │ ├── pre.sh # CIで使用するファイル │ └── ... │ ├── packages # すべてのパッケージのルートです │ ├── asoview # 各サービスや機能、プロジェクト、役割単位ディレクトを作成します。作成は通常であればリポジトリを分割するようなケースを想定しています。 │ ├── point-service │ └── ... │ ├── README.md # このファイルです ├── init.sh # プロジェクトの初期化処理を行います。新たにcloneした場合や、設定を更新した場合に実行します。 └── migration.sh # 既存リポジトリのマイグレーションを実行します。詳細はスクリプトのコメントを確認してください。
※MonorepoのREADME.mdからの抜粋
また、packages配下は基本的にフラットな構造にしており、技術軸や概念、プロジェクトなどによるサブディレクトリは作成しませんでした。
移行方法
今回の移行には、Gitの履歴、ファイル移行のために hraban/tomono を利用しました。
tomonoはシンプルなシェルスクリプトで作られており、各リポジトリのGitの履歴とファイルをMonorepoに移行するのには必要十分な機能を備えていました。
手順としてはローカルに移行したいPolyrepoと移行先のMonorepoをcloneし、以下のようなコマンドを実行すれば移行完了です。
MONOREPO_NAME=monorepo REPO=polyrepo echo "git@github.com:asoview/$REPO.git $REPO packages/$REPO" | tomono --continue
Monorepo管理ツール
Monorepoには管理を効率的に行うための管理ツールが多数存在します。
しかし、今回の移行では専用の管理ツールを導入しないこととしました。
理由として1番大きかったのは、既存のPolyrepoで使っているビルドツールやバージョンなどが異なるものが多数存在していたことです。
これらを1つの管理ツールに統合するには、多くの設定変更やテストが必要となり、移行にかなりの時間がかかることが想定されました。
また、単一言語の管理ツールであれば統合もしやすいですが、複数言語対応をしている管理ツールは学習コストが高いものが多く、既存の運用を大きく変える必要性が高かったというのもあります。
完全に1からMonorepoを作るのであれば別ですが、既存の運用を大きく変えず、柔軟性を維持し、学習コストを最小限におさえるため、この移行時には新たな管理ツールは導入せず、移行後のパッケージ単位でそれぞれのビルドツールを起動する最小限のシェルスクリプトを利用するようにしました。
以下は、当時検討したツールです。
多言語対応した管理ツール
BazelはGoogleや他社の利用実績も多く、アソビューで利用している大半の言語のサポートも標準で揃っており、Monorepoの管理に必要な機能も充実していましたが、既存のビルドツールからの置き換えや、ビルドシステムを扱う学習コストの高さがネックとなりました。 bazel.build
また、複数言語に対応した管理ツールとしてNxやPants、Buckなども検討しましたが、Bazelと同じく多言語対応するだけあって様々なサポート機能が含まれており、スピードを重視している移行プロジェクトにおいて、やりたいことに対し開発者に求める知識のオーバーヘッドがかかることは同様でした。
nx.dev www.pantsbuild.org buck.build
最後まで悩んだのがGradleでした。
Monorepoの管理ツールとしてそこまで広く使われている訳ではないですが、Javaのマルチモジュールプロジェクトとしてはよく利用されており、アソビューのバックエンドでメイン言語としている、Javaプロジェクトの標準ビルドツールとしてGradleを採用しています。
社内でのナレッジも多く、Gradle自体はJVM系のビルドはもちろん、プラグインなども充実しており多言語のビルドや必要であれば、自分たちでプラグインを作ることも容易にできます。
検証期間をある程度作れば導入も考えられたかもしれませんが、期間的な制約やバックエンドの技術に寄りすぎる懸念もあったため、移行時点での導入は見送りました。
JavaScriptのエコシステムに特化した管理ツール
2020年頃だとLernaは代表的な管理ツールの一つでしたが、JavaScriptに特化しており、今回は複数言語を管理するMonorepoという条件があり対象から除外しました。
※Lernaはコードロケーションツール的な位置づけですが、本記事では同様に扱っています。
lerna.js.org
また、RushやYarnなども同様JavaScriptのエコシステムに特化しているものも同様でした。
その他管理ツール
ここまで出てきたものの他にBitやPlease、MBT、Nix、oaoなども検討しましたが、要件を満たしていなかったりや導入事例が少ないものが多く、いずれも導入には至りませんでした。
bit.dev please.build github.com nixos.org github.com
CI/CD
アソビューではCIとしてCircleCIを利用しており、多くのPolyrepoでGithubの変更を検知してCIを実行するようにしていました。
Monorepo移行時にもこれらの仕組みを移行する必要があり、最終的にはMonorepoの大きなworkflowを作ることで対応しました。
これらのworkflowでは、全てに対して毎回ビルドやデプロイが発生すると非効率となってしまいます。
そのためGithubへの変更トリガーでworkflowを起動した後、gitの履歴の中からCI対象となるパッケージを特定し、そのパッケージ以外のjobはskipするようにしています。
この処理により、移行前のリポジトリで利用していたCIをそのまま再利用できるようにしています。
その他にも、preとpostという全てのworkflowの開始と終了処理を用意し、workflow内で利用するような共通的なセットアップや開始/終了通知、リリースノートの自動作成などを実行するようにしています。
特に移行当時の2020年頃は、CircleCIにMonorepo向けの機能がほとんどなく、このような仕組みを構築しました。
いくつか制約はありますが、現在であればCircleCIのダイナミックコンフィグをを利用することで、改善できる部分もあると思います。
ブランチ戦略
Polyrepoで運用していたリポジトリに特に明確なブランチ戦略は指定していなかったため、当時はリポジトリ単位で任意のブランチ戦略を利用していました。 その中でも特に多かったのがgit-flowですが、Monorepoに移行したタイミングで、GitHub Flowベースへと移行しました。
git-flowではmain(master)ブランチへのマージに向けてdevelopブランチを経由しますが、Monorepoになると複数のリポジトリで行っていた開発が、developブランチに集約することになり、ブランチ単位で独立した並行開発が難しくなります。
そのため、mainとfeatureという単純なブランチ構成となるGitHub Flowを利用することとしました。
この構成にすることにより、feature単位の開発を個別で行い、mainマージで本番へのリリースなどを行えるようにしています。
移行当時には、Googleなどで利用されているトランクベース開発も検討しましたが、実現する上で重要となる自動テストやFeatureフラグなどが整っていなかったため、見送りました。
移行しなかったもの
既存の運用を変えないことを想定していたため、多くの設定や仕組みは移行していますが、その中でもいくつかは移行しなかったものがあります。
完全なGit履歴
hraban/tomonoを利用することで大半の履歴移行は自動で行えますが、Gitの仕様上、ファイル移動時に新規作成扱いになってしまい一部履歴が失われてしまうファイルがありました。
可能な限り残したい部分ではありましが、ファイル単位で個別に修正する作業もかなり大変な部分が多く、一部の欠損は今回は許容することとしました。
リポジトリ単位のIssueやPR
GitHubのIssueを使っていたリポジトリもいくつかありましたが、社内的に課題管理にJIRAを利用するケースが多かったため、Issueの移行は行わずJIRAによる運用に変更するようにしました。
また、各ブランチをMonorepoに移行しなかったこともあり、PRの移行も行いませんでした。
そのため、リポジトリを利用している開発チームと日程を決め、移行タイミングではPRが新規に作られないように調整しながら実施しました。
EOL間近のリポジトリやpublicリポジトリ
リポジトリ単位の移行は比較的素早くできますが、それでも一定の作業は発生するため、EOL等の予定が決まっているものはMonorepoへの移行は行いませんでした。
またpublicリポジトリは移行してしまうとprivateになってしまうため、移行対象から除外しています。
💡アソビューでのMonorepo
ここからは、Monorepo移行により実際に得られた効果や考察を紹介していきたいと思います。
一覧性と主体性
Monorepoに移行することにより、今までは存在すら知らないものが多かった状態から、アソビューで働いているメンバーであれば誰でもローカルで全てのソースやドキュメントを閲覧、コミットが可能になりました。
全てのソースを見るとなると認知負荷が高まるようにも思いますが、パッケージ単位で見ればPolyrepoと変わらないこと、またアソビューでは一人一人がプロダクト全体に対し影響力を与えて欲しいと考えており、そのために全てを見通し、変更しやすくすることが重要でした。
数値化するのは難しいですが、実際に移行前と比べ組織の人数は増えていても、ソース全体に対する主体性が上がっているように感じています。
一括適用と全体最適
Monorepoの大きなメリットして、関係する変更を一括で行うことができることです。
Polyrepoから移行したことにより、よくある複数のアプリケーションやIaCなどのコードを1ブランチで開発しやすくなりました。
また、プロダクト全体で行いたい設定変更なども、1コミットで行ったり、一括でできるようになり変更コストが大幅に削減されています。
例えば、GitHubのブランチ保護ルールを導入した際にも、単一のリポジトリにまとまっていることで一括で適用することができました。
これがPolyrepoの場合には100以上あるリポジトリ、ブランチの運用ルールを考慮しつつそれぞれ適応が必要であり、Monorepoと比べ数十倍の時間がかかっていたものと思います。
その他にも、以前はオーナーシップが曖昧になり、管理が甘くなっていしまっていたリポジトリなどもなくなり、組織全体として実現したいルールを適用したり、テンプレート化するのにも貢献しています。
メトリクス
以前は組織全体のメトリクスを収集するには、各リポジトリやサービスから提供されている情報を集約する必要がありました。
また、リポジトリの作成ルールなどもあまり整備できていなかったため、次々と新たなリポジトリが作られ集約しようにもどこまで集約するか判断できる人もほとんどいない状態でした。
Monorepoに移行したことにより、メトリクスの多くはサービスが標準で提供している範囲で確認できるようになりました。
例えば、GitHubのMonorepoのページを開けばどれくらいアクティブなPRがあるかやInsightsでどれくらいのコミットが行われているか、Securityを見ればどれくらいのリスクを抱えているかなど、組織全体としてすぐに確認することができます。
現在ではプロダクト組織も70名程度に増え、組織全体で1日に平均10回以上本番リリース(mainリポジトリへのマージをトリガーにCI/CDが動いている)を行うリポジトリへと成長しています。
立ち上げコスト
Polyrepo時代に新規でリポジトリを立ち上げる場合には、リポジトリごとソースの構成や設定やブランチやPR、Issueなどの運用ルール、CI/CDの作成など一通りのセットアップを毎回行う必要がありました。
立ち上げが多い組織では、これらを楽に行うためにテンプレートプロジェクトなどを作る場合も多いと思いますが、Monorepoに移行することで新規立ち上げ=リポジトリ内のディレクトリ追加になるため、従来必要としていたセットアップが大幅に軽減されました。
また、Lintやテストなども既にセットアップ済みのものを使い回すこともでき、従来リポジトリを横断して作らなければならなかった仕組みが、単純なパス指定で完結させることができます。
すべてにおいてMonorepoか？
Monorepoで2年以上運用してみて感じる部分ではありますが、必ずしもすべてを1つにしなくても良い場合もあると思います。
全てを1リポジトリを集約する以外の、集約パターンをいくつか上げてみたいと思います。
技術単位でMonorepo
OSSのリポジトリやMonorepoを導入している企業でよく見られる構成で、JavaScriptやJavaなど言語単位などでMonorepoを構成する方法です。
完成度は様々ですが各言語が持つビルドツールがMonorepo対応をしている場合、非常に簡単に整った仕組みが構築できます。
組織や事業、サービス単位でMonorepo
ある程度大きな組織な場合にはとり得る選択肢だと思います。
特にMonorepoの場合、そのリポジトリにアクセスできるユーザーの制限が困難なため、組織上のポリシーなどが存在する場合にはこの選択肢になる可能性があります。
また、事業やサービス同士がほとんど関係性を持たない場合など、オーナーシップや自律性を分離したい場合に分割するということが考えられます。
ただし、GoogleやMetaなど数千人のエンジニアを抱える企業でもMonorepo運用を行っていることから考えると、大規模な組織だからといって必ずしもリポジトリを分ける必要は無いものと思います。
Monorepoにできないものを除外
昨今、多くの言語やツールはMonorepo対応を取り入れていますが、一部対応ができていないものも存在します。
例えば、ツールの制約上リポジトリのルートの構成が決められているような場合です。
そういった場合には、必然的に別リポジトリに切り出す必要が出てきます。
アソビューではnpmやPythonの自動生成されたgRPCライブラリの置き場としてGithubのリポジトリを利用しており、これらはMonorepoから切り離したライブラリごとのリポジトリとして運用しています。
ただし、自動生成以外のコードなどをMonorepo以外のリポジトリに置き出すと、達成しようとしていた目的ができなくなるため、基本行わないようにしています。
このように実際にはMonorepoだから全てを1つにするとは限らず、これらのリポジトリ分割とうまく組み合わせて運用することになると思います。
ただし注意が必要なのは、複数リポジトリに分割しても企業や組織横断で実施したい機能やポリシーがあるので、分割が進めば進むほど機能横断の仕組みが必要になるためトレードオフを踏まえ検討する必要があります。
🚀 現在の課題と今後の展望
移行時は優先度の高い目的を達成するために、スピード重視で移行を行いました。
また、移行から時間もたちMonorepoでの運用で新たな課題も見えてきています。
そのため今後やりたいと考えていることを上げていきたいと思います。
アトミックな変更
Monorepoの大きなメリットの1つが、Polyrepoではできなかった複数リポジトリを跨ぐような修正を一括してできることです。
現在アソビューではMonorepoにより、複数のアプリケーションを跨ぐような修正は1つのブランチでできるようになりましたが、依存関係が複雑なアプリケーションや、デプロイ順が重要な修正に関しては、個別にブランチを作って開発している状態です。
Monorepoはアトミックな変更は可能ですが、アトミックなデプロイを行うためのものではありません。
アソビューではCircleCIを利用し、mainブランチへのマージをトリガーに本番環境へデプロイする方式を採用しているリポジトリが多く、この方式を移行時にそのまま踏襲しているのが要因です。
mainブランチが常に本番と同期されているというのは、分かりやすい状態として良いのですが、CIとCDが密結合になりやすく、こういったデプロイプロセスを柔軟にしたい場合対応が必要となります。
また、Monorepo全体を管理するツールを導入せず、最小限のシェルスクリプトで実行しているため、高度な依存関係を管理するような機能が揃っておらず、今後この辺りの改善が重要になります。
Monorepo管理ツールの導入とCircleCI依存の軽減
Monorepo移行時にMonorepo全体を管理するためのツールなどは、導入を見送りました。
しかし、ある程度の期間運用してきた結果、依存関係のコントロールやビルドキャッシュなどの利用、CI/CDのコントロールなど、シェルスクリプトだけで表現するにはかなり辛い部分が増えてきています。
特にアトミックな変更を行った場合に、デプロイ順序を変更内容に応じてコントロールする必要もあり、CircleCIのworkflowで単純に実行するだけでは難しい場合もあります。
CIrcleCIは非常に優れたサービスですが、job間の依存関係や動的な条件分岐のコントロールなどMonorepoを扱う上では細かなところに手が届かなかったり、作り込む必要があります。
その他にも、CircleCIの機能に依存すればするほど、ローカル環境でのビルドと差分が生まれやすくなってくるという問題も存在します。
現在アソビューではアプリケーションの実行環境としてEKSを利用しており、一部のアプリケーションではArgo CDを利用してEKS環境へのCDを実現しています。
そのため、CIとCDを必ずしもCircleCIで実行しなくても良い環境も揃ってきています。
今後は、CircleCIに依存しすぎず管理ツール側で依存関係やビルドキャッシュ、分散実行などを管理できるようにし、CDへの連携とうまくつなげることで確実かつ効率的にCI/CDを行う仕組みを検討していきたいと考えています。
パッケージ単位の最適化
Monorepo移行によって、組織全体としての仕組みやルールの適用、メトリクスなどは非常に容易になりました。
一方で、GitHubやCircleCIのInsightsのようにリポジトリ全体に対しては利用できますが、ディレクトリ単位ではサービスやツールでサポートされていないものもあります。
今後はパッケージ単位で、独自の仕組みやメトリクスなどを導入できるようにし、課題の発見や解決をよりスムーズにできるようにしていきたいと思っています。
E2Eテストの充実
単体テスト等はPolyrepo時代からリポジトリ単位で実行していましたが、マイクロサービスのように複数のアプリケーションをデプロイしてからE2Eテストを実施したいケースも多いと思います。
CircleCIのworkflowを統一したことにより、複数のアプリケーションをトリガーにE2Eテストを実行することが容易になったため、今後はAutifyなども利用しテストの充実を図っていきたいと考えています。 tech.asoview.co.jp
肥大化するリポジトリへの対応
Monorepoの課題の一つが、リポジトリの肥大化です。
現在アソビューのMonorepoは5.6G程度のサイズになっており今後も肥大化していくことになります。
ローカル環境にcloneするのであれば初回は時間がかかりますが、それ以降のpullは一瞬で終わるため問題となりません。しかしCIなど繰り返し初回cloneを行う環境ではこの時間や容量がそのまま問題になります。
また、巨大なバイナリファイルなどをコミットしないようにするなど、運用時の考慮なども検討していく必要があります。
partial cloneやshallow clone、sparse checkoutなどGitで巨大なリポジトリを扱うための機能なども活かし、快適にMonorepoを扱える環境を構築する必要があります。
👍最後に
今回は、アソビューにおけるMonorepoの事例を紹介させてもらいました。
アソビューではMonorepo移行により開発者が自らサービス全体を見渡し、開発や改善を行いやすい状態を構築してきました。
一方で、その中で生まれてきた課題もあり、今後アップデートも多数行っていきたいと思ってます。
大量にあるリポジトリをMonorepoに移行というと非常に大きなプロジェクトに感じるかもしれませんが、スコープ次第では非常にコンパクトな対応で終わると思います。
Monorepoに興味のある方や現在Polyrepoに課題を感じている方、既にMonorepoで運用されている方などなど、参考になれば幸いです。
自身でサービスを成長させていきたいと感じていたり、この記事の中にある課題に挑戦してみたい方など、アソビューでは一緒に働くメンバーを大募集しています！
カジュアル面談もありますので、少しでも興味があればお気軽にご応募いただければと思います！
