この記事のターゲット
- GitHubが使えない制約の中でCI/CDを構築したいエンジニア
- Backlog Gitを使っているが、デプロイを手動で行っていてコストを感じているエンジニア
- 複数のフレームワーク(Vue/React/静的)が混在するプロジェクトの自動化を検討しているエンジニア
1. 制約・課題
こんな構築にした背景には、制約・課題がありました。
制約
当時企業として契約していたサービスがBacklogとAWSのみだったことです。GitHubを使う選択肢もありましたが、新たに契約し、権限管理などの運用ポリシーを一から整備する時間的余裕がありませんでした。そのため、既にあるBacklog Gitを起点にCI/CDを構築する方針を取りました。
課題
プロジェクトごとにリポジトリが用意されている中で、それぞれが静的サイト(SSG)なのか動的サイト(SPA)なのかを、リポジトリごとに手動で判断しなければならなかったことです。案件数が増えるにつれ、その都度ビルド設定を個別に用意していては運用が回らなくなることが見えていたため、Push時に自動でこれを判別できる仕組みが必要でした。
さらに、利用ユーザーはBacklogからの設定のみで利用出来るようにするため、利用時の学習コストを下げる必要がありました。
2. 全体アーキテクチャ
このパイプラインは、Backlog Gitへのpushを起点に、共通のWebhookエンドポイント(API Gateway)がイベントを受け取り、そこから静的サイト(SSG)向けとSPA向けの2つの経路に分かれる構成になっています。
どちらの経路を使うかは、プロジェクトごとに登録するWebhook先で決まる形にしており、リポジトリの種類に応じて適切なビルド・デプロイフローに流れるようにしています。
3. 経路1:静的サイト(SSG)配信の仕組み
Push検知後、LambdaがCodeBuildのビルドを起動し、ビルド成果物をS3にsyncします。配信はCloudFront経由で行い、Lambda@Edgeでリクエスト・レスポンスの書き換え処理を行っています。ドメインの名前解決にはRoute53を使い、企業ドメインでアクセスできるようにしています。
4. 経路2:SPA(Amplify)配信の仕組み
Amplifyは直接Backlog Gitと連携できないため、CodeBuildで一度CodeCommitへミラーリングし、そのビルド成功をEventBridgeが検知してから、LambdaがAmplifyアプリの生成・デプロイを自動で行う流れにしています。ドメインはAmplify標準のカスタムドメイン機能を使って設定しています。
5. 工夫した点
複数のプロジェクト・フレームワークを同じ仕組みで扱うため、Backlog GitへのPush時に、リポジトリ内の設定ファイル(package.json)を参照して、Nuxt(Vue)/Next(React)/静的ファイルのどれかを自動判定する仕組みを組み込みました。これにより、リポジトリごとに個別のビルド設定を用意する必要がなくなり、新しいプロジェクトを追加する際の手間を大きく減らすことができました。
さいごに
GitHubが使えないという制約は、一見するとCI/CDを組む上での不利な条件に見えます。ただ、既にあるBacklog Gitを起点に据え、静的サイトとSPAという性質の異なる成果物をそれぞれに合った経路(S3+CloudFront、CodeCommit経由のAmplify)へ振り分ける形にしたことで、案件が増えても同じ仕組みに乗せられる基盤を作ることができました。
特に、Push時の設定ファイル参照によるフレームワーク自動判定は、リポジトリごとの個別対応をなくし、新しいプロジェクトを追加するコストを大きく下げてくれました。手元にあるサービスの制約をどう組み合わせて解決するかという視点は、大きなクラウド予算やツールを自由に選べない環境でも役に立つはずです。同じような制約を抱えている方の参考になれば幸いです。