株式会社HighLink ロジスティクスエンジニアのかんたろう(@kantarow)です。
私たちは複数のチームで一つのステージング環境を利用しています。masterブランチが更新されるごとにステージング環境へのデプロイが行われ、リリース前には必ずここで動作確認を行います。
このmasterマージによるデプロイには問題が無いのですが、master以外のブランチの動作確認を行うために手動デプロイを行った場合、ステージング環境での検証が中断される問題が起こります。
そこで、Pull Requestごとに自動で検証環境を立ち上げる仕組みを構築することで、この課題を解決しました。
本記事では、この解決方法に至った経緯と、運用を始めて改善されたことをご紹介します。
これまでのリリースフローの問題
カラリアの開発では、masterにマージされた変更が自動でステージング環境にデプロイされ、担当する開発者やデザイナーによる検証が行われます。masterへの変更が全て検証されたことを確認したら、リリースタグを切って本番環境への自動デプロイをトリガーします。
しかし、master以外のブランチを手動でステージング環境にデプロイした場合、masterブランチの検証が中断される問題が起こります。
以下の図は手動デプロイによりmasterの検証が中断される流れを示しています。
初期状態でfeature Bはmasterの検証完了を待たされています。その後feature Aがマージされ、masterの検証は継続されますが、その最中にfeature Bが手動デプロイされてしてしまいます。本来なら未然に防ぐべき事態ですが、少しのコミュニケーションミスで簡単に起こり得る状況です。これによりmasterの検証は中断され、feature Bの検証完了まで待たされることになります。
さらに厄介なのが、masterにマージしたいブランチCが存在する場合、Bの検証が終わるまでマージできないという点です。当然のことですがmasterにマージしないとリリースできないので、リリースフローが滞ります。
このように、従来の運用でステージング環境が混雑するとリリースフローに悪影響を与えることがわかります。
ここで起こっている問題を整理すると、master以外のブランチを検証する環境が無いことに集約されます。先述の通りmasterマージによるデプロイのみの運用では中断の問題が起こらないため、master以外のブランチの検証環境を立ち上げることにしました。
理想のステージング運用
master以外のブランチ用の検証環境を立ち上げるにあたり、いくつかの方法が考えられます。
まず部署ごとに検証環境を立ち上げる方法ですが、部署内でも競合は起こり得るので大きな効果は得られないと考えました。部署ごとに複数個の環境を用意することも考えられますが、誰がどの環境を使っているか把握する必要があり、余計複雑さが増します。
そこで、実装コストが高くつくとしてもPull Requestごとに検証環境を立ち上げられるようにするのが良いと考え、方針を固めました。
以降はこの環境を「PR検証環境」と呼びます
以下の図はPR検証環境を導入した後の運用イメージです。マージされていないブランチはPR検証環境で検証可能なので、手動デプロイの必要性がなく、検証待ちの状態を無くすことができています。
GitHub Workflowを使ったAWSへの自動デプロイ
弊社はインフラにAWSを利用しており、自動デプロイはGitHub Workflowを用いて実装されています。
今回作るPR検証環境では、通常のデプロイに加えていくつかのAWSリソースを動的に作成する必要があります。
以下に最終的な構成図を示します。
リクエストはリスナールールによりターゲットグループに振り分けられます。リスナールールはホストヘッダを見るように設定されており、例えばPR番号が1234番なら1234.xxxx.jp にマッチングするようにします（ホスト名を一部伏せています）。
ターゲットグループはECSのサービスと紐づけられているため、リクエストはサービス内で動作しているコンテナに到達します。
この構成を自動で作成するには、リスナールールとターゲットグループ、ECSサービスを自動で作成する必要があります。また、PRに新たなコミットがプッシュされた際に再度デプロイする必要があります。
さらに、自動デプロイを適用するプルリクエストを識別する必要があります。今回は専用のラベルを利用することで実現することにしました。ワークフローはプルリクエストへのラベル追加、またはラベルが付与されたプルリクエストへのコミットの追加によって発火します。
以下にフローを示します。
また、ここで作成されたリソースは自動で撤収する必要があります。今回はPRのクローズ、タグの削除を発火条件とし、自動的にAWS上のリソースを削除するようにしました。
導入後の運用
PR検証環境の導入により、以前の運用で起こっていた問題は解決されました。
特にデザイナーによるチェックが必要なタスクが複数進行している場合、検証対象の環境のURLを送るだけで済むようになりました。また複数のレビューが溜まっている状況でもStaging環境にデプロイし直す手間がありません。PdMによる確認が入る場合も同様です。
おわりに
今回は、ステージング運用の問題を整理し、PRごとに検証環境を立ち上げる仕組みを作ることによってリリースフローを改善することができました。
事業成長に伴い、素早く複数の開発を進めていかなければならない状況で、PR検証環境は今後も大いに役立ってくれると考えています。
私たちはこのような開発基盤の整備にも関心があるエンジニアを募集中です。
興味がある方はカジュアルにお話をするだけでも歓迎です。詳細は下記のリンクからどうぞ！
