概要
仕事でマイクロサービス移行にともなってモノレポを採用した。 その理由をまとめる。 具体的な内容には触れない。
課題
長らくモノリスで開発してきたことによる
- コード量の増加
- テスト時間の増加
- 依存関係によるデプロイの遅れ
- 開発者への依存
が課題になっていた。
改善方針
これに対して、
- マイクロサービス分離
- モノレポによる開発体験の統一
によって解決を図った。
具体策
サービス分離
機能単位でモノリスアプリケーションを分離し、サービスごとに開発サイクルを回せるように
コードの変更差分に対してのみCI実行、サービスごとにCI並列実行サービスごとに独立したデプロイ
Gitタグで任意のタイミングでサービスごとにDockerイメージを作成し、デプロイ
これにより
- CI実行時間の削減
- ワークフローの統一化
- デプロイの依存関係の解消
を実現した。
モノレポ
npm workspaceを利用、モノレポフレームワークなし
開発ワークフローの統一
差分実行、並列実行
GitHub Actionsで変更差分に対してのみCI実行、サービスごとにCIを並列実行セットアップの自動化
Makefileを実行するだけで開発をはじめられるように
なぜモノレポか？
工夫するとポリレポでもモノレポのメリットの一部は実現できる
- GitHub Template Repository(マイクロサービスのテンプレート)
- GitHub Actions Reusable Workflow(CIワークフローの共通化)
- GitHub Actions Repository Dispatch(リポジトリ間のCIトリガー)
- npm packageによる設定ファイルの共通化
チームのコラボレーションのため
- 特定の機能が特定の開発者に依存しつつある
- 特定の開発者しかメンテナンスしないリポジトリがある
- コードを共有する仕組みが整っていない
これらの課題を解決するため
セットアップの仕組み化と適切なサービス分離により、認知不可を低めつつ
担当していないプロダクトコードも目に入りやすい状況を作る。
また、プロダクトコードはすべて一つのリポジトリにある状況を作ることで、リポジトリの管理が不要になる。
依存関係の解決のため
現状OpenAPIを別リポジトリで開発しており、 開発時の依存関係解決のワークフローを簡潔にしたい
今後必要なこと
CIプロセスの継続的な改善
開発が進むにつれビルドや静的解析の速度が課題になるCDプロセスの改善
プログレッシブデリバリーマイクロサービス化に向けた組織構成について
現状の組織構成のままやっていけるかチーム内で検討
まとめ
開発ワークフローの課題をサービス分離にともなって解決していっているという話を書いた。
一番の目的は開発サイクルを早め、市場の変化に対応すること
現在、開発基盤を大方作り終え、今後フィードバックを受けながら改善していく
マイクロサービスや開発チームが増えてきたときに、開発体験が悪くならない仕組みを作る
CIの差分実行・並列実行、CIの共通化、セットアップの簡略化などで実現モノレポを採用することでチームのコラボレーションを促進する
