フロントの動作確認用の環境をGithub Actionsで自動構築してみた

AlphaDrive、NewsPicks兼務でエンジニアしているスギウラ (saba-can00)です。今回、Github Actionsを利用してコードをpush すると動作確認ができるコンテナが自動で立ち上がるように環境整備したので、その内容をまとめます。

背景

Webのリアーキテクチャプロジェクトにおいてlocalで実装した画面をmainブランチにマージする前にBFFやバックエンドと連携した状態で確認したいというニーズがありました。

さらにGithubにプッシュすると環境がさくっと立ち上がるとDX的にすごく嬉しいということでGithub Actionsをトリガーとした環境の自動構築をチームで進めることにしました。

今回対応した内容

今回対応した内容はざっくり下記の3点です。

topicブランチへのpushをトリガーとして、動作確認用の環境を作成する
すでに環境が存在しているtopicブランチへ追加のpushをすると動作確認用の環境へコードが自動で反映される
対象のtopicブランチが削除されると動作確認用の環境も削除される

下記、それぞれ対応した内容とつまづいたポイントを紹介させていただきます。

環境の作成

上記の図のようにGithubへのpushをトリガーとして、下記の手順でリソースの作成を行なっています。

[環境作成の手順]

ECR へログインし、最新のソースを反映させたDocker image をビルド / プッシュ
ブランチ名ごとに一意のタスク名でタスク定義を作成
ブランチ名ごとに一意のターゲットグループを作成して、既存のELBのリスナーに追加
ステップ3で作成したターゲットグループに紐付けたサービスをプロジェクトのECSクラスターに作成
slackチャンネルに作成した環境のURLを通知

[解説]

Github Actionsでは${GITHUB_REF#refs/heads/}と記述するとトリガーの元となったブランチ名を取得できるのですが、今回ブランチごとの環境を作成するために、タスク定義やターゲットグループの名前にブランチ名を利用しました。

既存の開発環境のドメインを利用したかったので、ブランチごとにportを新規追加してELBのリスナーに登録することで、利用してportを区別するだけで複数の環境の構築を行えるようにしています。

また、portをSlack通知するためにサービス作成時にタグにportを登録しています。

作成した環境へ新しいコードを反映

Update the development environment — 作成した環境へ新しいコードを反映

[新しいコードを反映する手順]

ECR へログインし、最新のソースを反映させたDocker image をビルド / プッシュ
ブランチ名ごとに一意のタスク名でタスク定義を作成
既存のサービスで新しいタスク定義を利用するように更新
slackチャンネルに環境のURLを通知

[解説]

手順としては、ほぼ環境の作成と同じなのですが、新しいタスク定義を利用するようにサービスを更新しています。

ポイントとしては、サービスの更新時に--force-new-deploymentのオプションを利用している点です。 Amazon ECS の仕様上、タスクのリタイアの時間まではタスクは存在し続けるため明示的に新しいデプロイを強制する必要があります。

環境の削除

[環境作成の手順]

対象ブランチのELBのリスナー / ターゲットグループを削除
対象のECSサービスを削除
対象のタスク定義の登録解除
slackチャンネルに削除したことを通知

[解説]

手順としては作成の逆順なのですが、依存関係があるためELBのリスナーを先に削除しています。

ブランチの削除をトリガーとする際の注意点ですが、Github Actionsでアクションを実行するタイミングではすでにブランチは存在していないため、GITHUB_REFではブランチ名は取れません。そのため、GITHUB_EVENT_PATHを利用して、jq -r .ref ${GITHUB_EVENT_PATH} のような方法で取得する必要があります。