Hono × GitHub Apps でマルチテナントデプロイフローを組んだ話

はじめに

プライベートで進めているプロジェクトで、複数サイトを1つの基盤で動かす仕組みを作成しています。今回はデプロイフローについて、背景や構成をご紹介します。

本記事で解説しないこと

• 具体的なコード、設定値
• ハマりポイント、トラブル等（特に詰まることがなかったため）
• 認証・認可などの権限、マルチテナント時におけるセキュリティ など

背景

全体構成がほぼ同じサイトが複数あるのですが、リポジトリを分けて管理しており、同様の変更を各リポジトリに対して行って回らなければならないという、メンテナンスコストの高い構成となっています。

• 一般向けサイト: Next.js SSG
• CMS管理画面: Vite + Tanstack Router
• CMS管理API: Hono
• データなど: Supabase + Cloudflare R2

※一般向けサイト/CMS管理画面/CMS管理APIは、それぞれ別のアプリとして、Cloudflare Workersへデプロイ・動作しています。

コードの変更対応が可能なメンテナーが現在私１人のため、できる限りメンテナンスコストを下げていきたいという気持ちがありました。

表示コンテンツやデザインが異なるNext.js製サイトと、データそのものを分離する必要がある部分については、これまで同様、分けて管理するほかありません。

ですが、データ構造自体はほぼ同じのため、管理画面やAPIはだいたいのロジックが共通化できます。であれば、１つのコードベースで複数サイト分の処理を行い、サイトごとの差分を切り替えるようにすれば、リポジトリを分けて管理する必要がなくなるはずです。

そこで、管理画面とAPIについてはマルチテナント構成とする方針を固めました。デプロイフローについても、この構成を活かして一元化することにしました。

具体的なデプロイフローについて、次章で紹介します。

構成

図に表すと以下のようになります（前述の通り、各テナントの認証・認可周りは省いています）。

ビルド・デプロイ周りについては、各本番WebサイトのRepositoryにあるGitHub Actions (Workflow)を活用します。

GitHub外からActionsを動かす方法はいくつかありますが、今回は『複数リポジトリに対して似たようなリクエストを送る』という観点から、GitHub Appを事前に作成して各リポジトリに導入、Appの権限を用いてGitHub APIを叩きActionsを動作させる、という方法を取りました。

Honoで作成したAPIに対して、POSTでビルドリクエストを送ります。この際、対象テナントの情報を含んでいます。
Hono API側では、テナント情報を元にどのリポジトリに対してリクエストを送るかを判断、その後GitHub APIを呼び出し、GitHub Appの権限を用いて各リポジトリのworkflowを実行する、という流れです。

APIを介さず、Frontend側で一通りのリクエスト処理を行ってしまう方法もありました。
ですが、デプロイするタイミングは手動実行だけではなく、記事の公開・編集など、一般向け本番サイトに影響する様々なタイミングで実行されます。また、API化しておくことで、後々、SlackやDiscordなどのBOTを介してリクエストを送ることもできるようになるため、今回のAPI化を選びました。

終わりに

この構成を思いついた後、構成の詰めや実際の実装は、ほぼClaudeで行いました。結果、良くも悪くもハマってしまうようなことはなく、問題なく動作しています。

AIの普及により、企画者・設計者のアイデア次第、ツール・実装のかけ合わせ次第で、できることはますます増え、それに必要な開発コストもかなり低くなってきていると感じました。

こうした試行錯誤も含め、今後もAIと一緒に、手を、頭を動かしながら、良い設計・実装を模索していきたいと思います。