まともな（信頼できる）ステージング環境を用意できてるウェブ系企業、肌感だけど5%以下という印象
— たにみち (@ttanimichi) 2018年8月20日
このツイートを見て弊社は5%に入れるかどうかを考えてみたいと思った。
が、そもそも何をステージング環境と呼ぶか、何をもって"まとも（信頼できる）"と言えるのかわからないのでそこから考えてみた。
ステージング環境とは
本記事中では「アプリケーション、システムの動作や表示を試験するための環境」とする。
試験の対象は機能・性能・外部連携などの多岐にわたる。また、試験を行うのはサーバサイド開発者、クライアントサイド開発者、デザイナー、カスタマーサポート、プロダクトマネージャ etc.…と、これも多岐にわたる。
まともであるために、ステージング環境で実現したいこと
少なくとも自分の感覚では、以下を実現できるのであれば良い開発体験（Developer Experience）が得られる、"まとも"なステージング環境を持っていると言えそうだ。
1. ステージング環境のアプリケーションが接続するステージング環境用データベースは、本番（production）のデータベースと同期されている
- 個人情報は除く
- 日次間隔で自動的に同期しているとなおよい（hourlyだと短すぎて操作中にデータが書き換わる。そもそもリストアがそんなに短時間で終わらない。などの問題がある）
- 本番相当のデータで試験することの重要性は開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログにまとめられている
2. 任意のブランチを独立した専用のインスタンスにデプロイすることができる
- feature branch を GitHub などに push するとCIでテストが実行され、テストがパスした場合のみステージング環境が自動的にデプロイされる
3. 特定のブランチは常に特定の名前でステージング環境にデプロイされる
- 後述する Edge, Develop などの環境が常に存在し、継続的にアップデートされることを保証する
4. ステージング環境のアプリケーションのプロセスコントロール、環境変数設定は開発者が自由にできる
5. 外部連携の試験ができる
- 外部連携先の保持するデータとこちらのデータに一貫性がある
- この要件は外部連携先のステージング環境に依存するので本番相当のデータを使えないことが多い
6. 本番相当の負荷試験ができる
- 本番相当のアクセス数・データ量・サーバースペックがある
- 常時その状態にする必要はなく、特定のタイミングでその状態にできればよい
7. multirepo構成の場合、協調して動作するアプリケーション群の任意のステージング環境から任意のステージング環境に接続できる
- たとえばクライアントサイドのSPAとサーバサイドのAPIエンドポイントを同時に開発しているとき、前者の feature branch に対応したステージング環境から後者の feature branch に対応したステージング環境に接続したい
8. monorepo構成の場合、feature branchをそのままステージングクラスタにデプロイできる
9. アプリケーションの振る舞いに作用する環境変数を production と揃えている
- Rails でいえば
RAILS_ENV=productionで動かしていること - 開発中の機能を production では隠す、staging では表示する、みたいな feature flag は揃えなくてよい
他にもあるかもしれないがとりあえずの思いつきを列挙してみた。弊社 Quipper はすべて実現している（はず）
ステージング環境の種類
上述の要件のうち幾つかは互いにデッドロックしあってしまうので、たった1つの環境で補うのは不可能だ。そのため各々に適した環境のセットアップが必要になる。
Quipper で実現している環境を用途ごとにまとめた。
本番で発生したバグや問い合わせを再現したい
主にカスタマーサポート（非開発者）が利用している。開発者もデバッグ用途でよく使う。
- 本番相当のデータ＋本番にデプロイされているのと同じバージョンのアプリケーションが動作する環境
- 弊社では Edge 環境と呼んでいる
開発中の最新の動作を見たい
- 本番相当のデータ＋develop branch のHEADのアプリケーションが動作する環境
- Edge 環境とは異なるデータベースを用意している
- 弊社では Develop 環境と呼んでいる
次回リリースされるバージョンの動作を見たい
主にQAを行う環境。
- 環境固有のデータ＋Develop環境のある時点でfreezeしたバージョンのアプリケーションが動作する環境
- 弊社では Release 環境と呼んでいる
本番相当のデータをあえて用意せずに環境固有のデータを用意している理由は以下。
- 外部連携をテストする（外部のデータベースと一貫性を保つ必要がある）
- テストデータが自動的に上書きされないようにする（current streak とか連続ログインボーナスとかの試験をしたい）
特に外部連携が曲者で、連携先が社外のベンダーでコントロールできないことがほとんどになる。
開発者、非開発者がある機能のレビューをしたい
詳しくは非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog参照
- 本番相当のデータ＋各開発者の feature branch のアプリケーションが動作する環境
- 弊社では Staging 環境と呼んでいる…が正確ではなく、Feature Staging などと呼んだ方が良さそうだ
結論
うーん、思いつく範囲では"まとも"は満たせていると思うが、どうだろうか。
こういうのはあれば当たり前と思ってしまうが、そもそも体験したことが無いと存在の可能性にすら思い当たらないことがしばしばある。自分も現職に入ったときは「こんな便利な仕組みあったのか！」と思ったし、次の職場で何かが欠けていたら「開発体験が悪い…直さねば」と思うだろう。
なので、皆さんの考える"まとも"の(必要|十分)条件があれば教えて欲しいところ。
