はじめに
こんにちは！株式会社ブロードエッジ・ウェアリンク CTOの高丸です。
今回は、Qiita Advent Calendar 2024の10日目の記事です。
3日目の記事で、スクラム開発の取り組みについて紹介させていただきましたが、今回はその開発フローをより効率的にするために欠かせない「feature環境」についてお話ししたいと思います。
feature環境とは機能検証のための環境で、我々の開発フローの中で重要な役割を果たしています。
開発チームのメンバーが増えてきた中で、効率的な開発フローを実現するために我々が取り組んできたことをご紹介できればと思います。
どれくらいの環境ありますか？
みなさん、本番とローカル環境以外にどれくらいの環境をお使いでしょうか？
多くのプロダクト開発では、テスト用のステージング（STG）環境を用意していると思います。
実は、弊社も当初はSTG環境のみでした。これは、ShopifyがDEVモードを提供していたこともあり、それに相当する環境だけで十分だと考えていたのだと思います。
しかし、私がプロダクトチームを作る上で目指していた「デプロイ頻度の向上」を実現するためには、より柔軟な環境構成が必要でした。単にデプロイの数を増やすだけでなく、バグフィックスを含む機能検証も数多くこなせる環境が求められるからです。
特に大きな転機となったのは、スクラムチームをフリーランスとインターンのメンバーに切り替えた時期でした。
最大で10名近くのエンジニアが同時に機能開発を行う体制となり、既存の環境構成では明らかに限界がありました。検証用の環境が常に埋まっている状態となり、リリースまでの待ち時間が開発のボトルネックとなってしまっていたのです。
この課題を解決するため、私たちは環境構成を見直しました。
現在は、Shopifyについては本番とSTG用の環境のみとしていますが、
フロントエンドのHydrogen（Oxygen）環境と、バックエンドのFastAPI（App Runner）環境については、本番・STG以外に5つのfeature環境を用意しています。
Hydrogen（Oxygen）環境に関して
フロントエンドのHydrogenについては、Shopifyが提供するOxygen環境に直接デプロイする形を採用しています。
Oxygen環境はPaaS（Platform as a Service）のような構成になっており、異なるブランチを個別の環境にデプロイできる柔軟な仕組みを持っています。
さらに、GitHubとの連携機能により、ブランチへのマージをトリガーとした自動デプロイも実現できます。
Oxygen環境は主に3つのタイプに分かれています：
Production環境は、デフォルトではGitHubリポジトリのデフォルトブランチに相当するブランチに対応する環境です。この設定は後から変えられます。
Custom Environments環境は、特定のブランチ名を指定してデプロイできる環境です。
Preview環境は、上記のいずれにも該当しないブランチがデプロイされる環境として機能します。
我々はこのCustom Environments環境を5つ用意し、feature環境として活用しています。これにより、複数の機能開発やバグフィックスを並行して進められる体制を整えています。
App Runner環境に関して
バックエンドのApp Runner環境は、他のコンテナオーケストレーションサービスとは異なる特徴を持っています。例えばFargateでは「クラスタ」や「サービス」「タスク」など複数の概念が存在しますが、App Runnerには「サービス」という概念しか存在しません。
そのため、5つのfeature環境を用意するためには、それぞれに対応する5つのサービスを作成する必要がありました。（VPC内にアクセスするための、VPCコネクタも5個必要となります……）
実は、私個人としてはGoogle CloudのCloud Runの環境が好きです。
Cloud Runでは「サービス」の中に「リビジョン」という概念があり、各リビジョンに個別のURLが割り当てられ、どのリビジョンがリクエストのトラフィック受けるかを設定することができます。
これにより、例えばSTG環境に100%のトラフィックを流し、メンバーみんながテストできる環境（STGのドメイン）としつつ、機能開発のメンバーだけが他のリビジョン（個別URL）にアクセスして機能テストを行うといった柔軟な運用が可能です。
残念ながら、現時点のApp Runnerにはこのような機能はまだありません。（が、将来的な実装を期待しています！）
ちなみにDBに関しては、理想的には各feature環境が独立したデータベースを持つべきかもしれません。
しかし、マイグレーション管理の複雑さや、データ同期の仕組みがまだ十分に整備できていない現状を考慮し、現在はSTG環境とfeature環境でデータベースを分離している状態です。
幸いなことに、この構成で今のところ大きな問題は発生していません。
またコストに関しては、7日目の記事でも紹介しましたが、
App Runnerはトラフィックが来ていないサービスに関しては、メモリだけが設定されている分課金される仕組みとなっており、ゼロスケールとまでは行きませんが、使われていないfeature環境があってもコストが抑えられるようになっています。
さいごに
今回は弊社のfeature環境についてご紹介させていただきました。
技術選定の際に、Oxygen環境やApp Runnerのように検証環境を柔軟に増やせるサービスを選択しておくことが、チームの成長に合わせた開発体制に大事なのでないかと思います。
Discussion