ウェブサービスをモノレポ化しようとして諦めた話

 あけましておめでとうございます。

現在技術アドバイザーとして参画している会社が提供しているウェブサービスは、いわゆるSPA構成でフロントエンドとバックエンドを完全に（リポジトリー単位で）分離しています。

新年一発目は、そんな分離されたサービスをモノレポ化しようといろいろ画策して最終的に諦めた話です。

なぜSPAか？

コレに関しては特別目新しい理由はなく、単純にフロントエンドとバックエンドを独立して開発できるというのが理由です。APIの入出力仕様さえ決めておけば、お互いに独立して開発できるので並列性が高く、開発スピードも上がりますよね。

あとは応答性が高いという理由もありますが、これは副次的なもので、一番の目的は開発効率の向上です。

なぜモノレポ化しようとしたのか？

多分これも目新しい理由ではないと思います。

このサービスは、フロントエンドとバックエンド（API）で別のリポジトリーを使っています。正確には、フロントエンドはさらに「ユーザーが使う画面」と「会社のスタッフが使う管理画面」の2つに分かれています。

それぞれのリポジトリーではデプロイにCIサービスを使っていますが、このときに問題になるのがバージョン違い・不整合。

新しいAPIを追加したとき、API側をデプロイするのを忘れてフロントエンドをデプロイしてしまうと、新しいAPIを使う部分でエラーが発生してしまいます。特にフロントエンドとAPIでチームが分かれていると、「もう新しいAPIがリリース済みかと思っていた」とか「新しいAPIだとは思わなかった（前からあるAPIだと思っていた）」のようなミスコミュニケーションが発生する可能性も大いにあります。

モノレポにすることで、（APIを含めた）新しい機能の開発はすべて単一のトピックブランチで行うようにすれば「マスターブランチにマージされた＝フロントエンド・バックエンドすべて含めて整合性のある状態に保たれた」なのでデプロイ時の不整合は発生しまいません。

あとは.editorconfigとか.gitignoreのような設定ファイルをサービス間で共有できるメリットもあります。

なぜ諦めたのか？

そんな理由でモノレポ化を本気で考えて色々準備を進めてきたんですが、CIに時間がかかるという単純な理由で現在は一旦計画を中止しています。

特にバックエンド側に色々APIを追加してきたので、自動テストの時間がバカになりません。開発当初は2分弱で完了していたのが、今では10分ほどかかるようになってきたためCIサービスの上限時間が迫ってきています。これをモノレポ化したら、フロントエンド側のコードだけをpushしたときにもCIが走るので間違いなく上限をオーバーしてしまうため、計画を中断中です。

というわけで、モノレポ化するには

• 札束で殴る（CIサービスにもっとお金を使う）
• CIサービスを使わない（自前のサーバーを用意してJenkinsやDroneを走らせる）
• CIにかかる時間を減らす（CI自体を高速化するとか、CIの回数を減らすとか）

このどれかにする必要がありそうです。札束で殴るのは最後の手段として、まずはCIの時間を減らす方向で現在再挑戦中。