開発を行うようになって思った事とリポジトリ（プロジェクトファイル群）について
ブログと平行しながら、いろいろな製品の開発（KuroNote等）を進めているわけですが、最近開発用のファイル管理が大変になってきました。今までは小規模で独立した開発だったので、リポジトリの管理も、無料の github に個別プロジェクトとして保管（昔はPrivateの数は制限されていた）していたましたが、どうやら最近は違うようです。
マルチリポジトリ方式の管理方法でおきたトラブル#
- 更新から製品のリリースまでが、製品やライブラリーごとに違って混乱・複雑化。
- KuroCMS などや KuroNote では、KuroEditor を利用しているが、別リポジトリなので基本は複製が各製品に置かれ、最新の更新にズレが出る。AI などを使っていると、この複製に更新を掛けられる時があり、本体と競合することすらある。
- .env などの秘密情報（Worker Secretや更新用のパスワードみたいなもの）が、それぞれの製品フォルダ毎に存在し、段々管理が大変になってきて、同じ名前で作った場合には、いつまで立ってもエラーから抜け出せなくなったりw
こんな感じで、デメリットが非常に目立ってきました。逆にメリットについても言及してみたいと思います。
マルチリポジトリのメリット#
- 独立性が高い：各プロジェクトで自由に権限管理やCI/CDの設定、ツール選定を最適化できます。特に WEB アプリなどでは、Github Action と組み合わせる事で、push するだけで、本番への自動 deploy ができるなど、利便性は高いです。が、この Github Action 無料枠が小さくて、頻繁に deploy すると直ぐに上限になり、使えなくなります。法人利用などで費用を気にしないのであれば良いですが、個人では素直に wrangler などの Cloudflare に直接 deploy するコマンドで対応したほうが、管理がシンプルになる場合が多い気がします。
- 軽量で高速：すべての製品毎にリポジトリを分割するため、リポジトリのサイズが小さいため、クローンやブランチ操作が高速に行えます。
- 影響範囲が限定的：1つのリポジトリの不具合や変更が、他の無関係なシステムに直接影響しにくいです。
但し、Cloudflare に deploy するWranglerコマンド には Wrangler の問題もあります。
一番の問題は、wrangler login で cloudflare にログインしているユーザーアカウントの切り替えです。個人と法人の２種類を使い分けるだけでも、毎回、OAuth 認証で切り替えなければなりません。開発者の場合はこの使い分けは必須なので、基本的には wrangler コマンドが持っている環境切り替え機能をお勧めします。これはコマンド利用時にどの環境を利用するか環境変数などを利用することで、１度ログインした認証情報を切り替えて利用できます。超お勧めです。
対抗馬のモノリポジトリーとは？#
これは、読んで言葉の通りなのですが、すべての製品を1つの巨大なリポジトリーに入れてしまうという、ある意味実も蓋もないやりかたです。しかし、マルチリポジトリのデメリットが解決する場合が多いです。
＜メリット＞
- コードの共通化が簡単：複製が作られず、他のプロジェクトの配置される場所がすでに1つのリポジトリーなので、複製を作らずに相対パスで最新のコードを import できる。常に最新が構造的に保証される。当然 AI が間違って複製側をせっせと直すミスもなくなります。
- 横断的な変更がスムーズ：APIとクライアントの仕様変更などを、1回のコミットで同時に修正・反映できます。それもAIによる修正では大きなアドバンテージです。AI はちょっと離れたり、別の作業をしていると前の事を平気で忘れたりします。なので、通常はライブラリーごとに、AI のセッションを区切ってライブラリー専用などの割り振りをさせたりするのですが、ライブラリーと製品側が別のセッションになると、当然AIのコンテキスト領域（学習領域）の内容に差が出るために、違う事を始めたりします😱。通常は AGENTS.md や仕様書などに書いておきますが、これをちゃんと見ないAIの多い事多い事w
- 全体像が把握しやすい：コード全体が1箇所にあるため、他のチームのコードも参考にしやすく、相互理解が容易です。
＜デメリット＞
- リポジトリの巨大化：コードが増えるにつれて、クローンやビルド、テストに時間がかかるようになります。しかし、これは github の部分 clone や 特定フォルダのみのコミットなどの活用によって、マルチリポジトリと同様のスピード感で開発を進めるようになってきているので、現代においてあまりデメリットというほどの物でもありません。
- 権限管理やCIの複雑化：リポジトリ全体に対して権限設定やCI（継続的インテグレーション）が動くため、分割や最適化に工夫が必要です。しかし、黒兎の開発ではスマホ向けのアプリなどが今後は主戦場でもあり、正直、CI/CD（開発からスムーズなテストをブラウザで行う）に対してもメリットをあまり感じていません。また先にも書いたように、wrangler を利用したきめ細かい deploy などを行うため、CI/CD は自前となり Github Action 使わない人にとっては元からデメリットにはならないです。但し権限管理は別です。しかし黒兎のチームは人間が自分だけですので、そもそも権限が不要という落ち。
CI/CD って何なのさ？
Continuous Integration（継続的インテグレーション）と Continuous Delivery / Continuous Deployment（継続的デリバリー / 継続的デプロイメント）の略で、簡単にいえば開発中に気軽に本番やテスト環境にアップして、すぐに結果を見る事で開発速度を上げる手法のことで、具体的な方法を指す事はないのですが、多いのは Github Action に Deploy を組み合わせる事で、git push しただけで、新しいコードが deploy され、すぐにコードの結果が確認できるようなイメージのものです。
そういう意味では、昔に流行ったアジャイル開発、エクストリーム・プログラミング（XP）などでも同様の目的の開発手法で、CI/CDの場合は deploy に特化した言葉という感じでしょうか。
実は昔から使われているモノリポジトリー#
そうなのです、実は世界の超巨大テック企業の多くが、昔からモノリポジトリ（モノレポ）を採用して開発を行っています。GAFAM（Google、Meta、Microsoftなど）に代表される大手企業は、何万人ものエンジニアが数十億行にのぼるコードを1つの超巨大なモノレポで管理していることで有名で、振興のUber, Stripe, Airbnb、Spotifyなどの企業でも、コードの再生産を行わないように、モノリポジトリーを使ってきました。
ただ大手さんでは、このモノリポジトリーを実現するために、独自の git 環境やプログラムを開発したり、自社に最適な開発環境への投資を行ってきています。当然、零細企業が同等のことを実現するのは難しいのですが、github の無料枠も大きくなったことから、零細企業でもモノリポジトリーの恩恵を工夫次第で利用できるようになってきました。
自分の開発した財産を、後続の製品でも無駄なく利用するために、またAI時代だからこそ AI に向いたシンプルな構造がきっと開発速度の向上に繋がると思います。