こんにちは、SREチームの森原(@daichi_morihara)です。 今回はニーリーのfeature環境の管理方法について紹介していきたいと思います。
feature環境
feature環境とは、新しい機能やバグ修正を検証するために作業用ブランチを、インフラにデプロイしたものを指します。ニーリーではこのfeature環境の管理をPRのラベルで行っています。ラベルで管理することで以下のような利点があります。
- 特定のPRのみに対して簡単にfeature環境が作成・削除できる
- PRのラベルとライフサイクルに紐づいているのでfeature環境の立ち上げっぱなしを防ぐことができる
- feature環境とブランチの紐付きが明確で管理が簡単
以前のブログでSREチームの大木がfeature環境(主にバックエンド)に関して詳しく紹介してくれているので、ぜひそちらもご覧ください。
バックエンドの話はそちらに譲ることにして、今回はfeature環境のフロントエンドとDBに関して紹介していきます。開発体験は当然優先しつつ、コスト的にも節約する工夫を入れているので、参考になれば幸いです。
feature環境のフロントエンド
フロントエンドのfeature環境構築が必要になる場面は2つ存在します。
1. フロントエンドをメインに動作検証を行う場合
この場合はフロントエンドのリポジトリのラベルでfeature環境を管理します。 接続先のバックエンドは自作のfeature環境のバックエンドかdev環境のバックエンドのどちらかになります。以下の画像の通り付与するラベルによって接続先は選択できるようにしています。
当初はfeature環境のバックエンドにのみ接続される仕様でしたが、開発メンバーから「必ずしも自作のバックエンドに接続したいわけではなく、毎回空コミットを送ってfeature環境のバックエンドを構築するのが手間である」というフィードバックを受け接続先(dev/feature)を選択できるように変更を加えました。
2. バックエンドのfeature環境の検証する際にフロントエンドが必要な場合
この場合はバックエンドのリポジトリのラベルでfeature環境のフロントエンドを管理します。例えば下の画像のようにラベルを付与すると、バックエンドとフロントエンドのfeature環境両方を構築することができます。フロントエンドが構築されるまでの手順は以下の通りです。
- バックエンドのワークフローが発火(ラベル付与)
- 1のワークフローがworkflow_dispatchを使ってフロントエンドのワークフローを呼び出す
- 2で呼び出されたワークフローがフロントエンドのfeature環境を構築
手順の2の際にバックエンドのURL等も渡すことでフロントエンドをバックエンドに接続させています。
feature環境のDB
デフォルトではfeature環境のバックエンドはdev環境のDBに接続しています。 しかし、マイグレーションを伴う検証を行いたい場合にはfeature環境用のDBを作成する必要があります。以前は手順書を読んで開発メンバーに手動で作成してもらっていましたが、いくつかの問題がありました。
1つ目はシンプルに手作業が手間であるという点です。
AWSに慣れていないメンバーにマネコンからDBを複製してもらう作業は、いくら手順書を作成していても煩わしいものでした。
2つ目はAWSの権限周りです。
手作業で操作するためには、開発メンバーにDB関連の操作権限を与える必要があります。また、DBの削除やタグの変更などは更に一部のメンバーに権限を絞っていたため、それらの操作を行いたい場合は他の権限を持つメンバーに作業を依頼する必要がありました。
タグで検証用DBの自動起動・停止も制御してるので変更が必要なこともしばしばあり、運用がややめんどくさかったです。
3つ目はfeature環境用DBの立ち上げっぱなし問題です。
DBのライフサイクルがPRと紐づいていないので、マージしたっきり削除を忘れているというケースが少なからずありました。これは前回の記事同様に無駄なインフラコストがかかってしまうので、同じような対応を入れました。
これらを解決すべくfeature環境のDBもPRのラベルで管理することになりました。 またDBを削除する際にスナップショットを作成するかどうかの選択もPRのラベルで制御しています。
ニーリーはCI/CDにGitHub Actionsを採用していますが、GitHub Actionsは時間課金されるので、20~30分ほどかかるDB複製を順に実行していくとコスト的によろしくないです。なのでここでもコスト節約の工夫を入れました。AWS Step Functionsで一連のフローをまとめてしまい、GitHub ActionsからはAWS Step Functionsを呼び出すだけにする形式にしました。
feature環境構築完了のSlack通知
feature環境の構築が完了(or失敗)した際の通知があると便利だよねというフィードバックを開発メンバーから貰いました。特にfeature環境でQAテストを行ってからマージするケースでは、QAメンバーとの連携が必要なため通知があると嬉しいとのことでした。
この意見を受け、feature環境の作成者にSlack通知が届く機能を作りました。デプロイが成功した時はfeature環境のURL、失敗した場合ワークフローの失敗した箇所のリンクを添付しています。SNS(Simple Notification Service)とAWS Chatbotを利用して一瞬で作れた機能ではありますが、開発メンバーからはとても便利になったとのフィードバックをいただき嬉しい限りです。
最後に
今回はfeature環境についてご紹介しましたが、開発メンバーの生産性向上を目的としたタスク、いわゆるプラットフォームエンジニアリングの領域においてもユーザー(= 開発メンバー)のフィードバックをもとに改善し続けることが大切なのではないかと思っております。開発体験の向上を目指し、ニーリーのfeature環境周りは現在でも新機能が追加され続けています。
ぜひfeature環境テックブログ第3弾にご期待ください！
