ステージング環境とは
e-Words のステージング環境 には以下の説明があります。
ステージング環境とは、情報システムやソフトウェアの開発の最終段階で検証用に用意される、実際の運用環境と変わらない環境のこと。
要するに本番環境とは別に、リリース直前の検証を行う環境ということですね。単体テスト・結合テスト・総合テストで言うところの、総合テストを行う環境とも言えるでしょう。
このステージング環境について考えてみたいと思います。
(2021.7.2追記)
明記してませんでしたが、主にウェブ系のシステム開発を前提としています。
(2021.7.2追記終わり)
なぜ必要か
開発環境でもある程度の検証はできますが、開発者以外は開発環境を持ってないことも多いです。社内の人間なら開発環境を用意しろということもできますが、クライアントならそうも言えない。そういう開発者以外の人にリリース前の動作を見せるのには、なんらかの専用環境が必要です。
開発環境はシステム全体の要素を持ってないことも多いので、単体テスト・結合テストまでは行えても、総合テストまでは無理ということもあります。
(2021.7.2追記)
開発環境が手元のPC上に構築されてる場合を想定していましたが、データセンターやクラウド上にある場合もありますね。その場合 URL を伝えれば開発環境を持っていない人でも検証できます。
もっとも、検証中は開発環境で別の作業ができなくなってしまいますので、やっぱりステージング環境が欲しくなりますけれども。
(2021.7.2追記終わり)
閲覧範囲
通常はステージング環境は特定少数の関係者だけが閲覧できるように設置します。クローズドな環境に構築したり、インターネットからアクセス可能でもアクセス制限を設けたりします。
逆に、パブリックベータで一般に公開する場合もあります。
構成
本番環境と同等の構成であることが理想ですが、現実的には難しい。本番環境が100台のサーバで構成されていたとして、ステージング環境も100台とするとコストがかかりすぎてしまう。なので、台数を減らしたり機器の性能を落としたりして節約した構成にすることも多い。構成が違うことにより負荷試験などが行えなかったり試験結果が正確にならないことがあり得ます。
OS、言語、ミドルウェアのバージョン
OS、言語、ミドルウェアなどは当然ながら本番環境と同じバージョンである必要があります。が、現実には様々な事情でバージョン違いの環境で検証せざるを得ないこともあります。バージョン違いによって試験結果が不正確になることを考慮しなければなりません。
データセット
試験するためにはデータセットが必要です。
データセットでまず検討しなければならないのはデータ量でしょう。100件のテストデータで軽々動作していて、本番環境の100万件のデータを扱わせたら重くて動かないでは話になりません。
本番と同量のテストデータセットを用意しても、データのばらつきの問題もあります。テストデータセットでは本番データとはデータのばらつきが変わってきますので、ばらつきに起因する動作や負荷の違いは検証できなくなってしまいます。
データセットのタイムスタンプも重要です。先月のデータを集計するシステムに対して、用意されたデータセットが1年前に構築したものだと、集計動作の検証が行えません。テスト用データセットを seed で用意するなら、現在日時を考慮して生成するようにするべきでしょう。
などなどのことを考えると、理想的なテストデータセットとは本番データセットということになります。本番で現在動作しているデータセットをステージング環境にコピーして使えるといいのですが、今度は機密漏洩の問題がでてきます。たとえステージング環境が社内に閉じていたとしても、厳密に言えば本番環境からステージング環境に機密情報をコピーしたら情報漏洩です。利用規約などでクリアできたとしても、別の問題もあります。実際のユーザのメールアドレスが登録されたデータセットを使ってメルマガ配信のテストを行ってしまったら大問題です。本番のデータセットを使って検証をする場合、機密情報はマスクして持ってくる必要があります。
本番環境との差異
ステージング環境は本番環境と構成が同一である必要があります。しかし、ステージング環境では本番リリース前のコードを検証しますので、厳密に言うとその時点で本番環境との差異が発生します。コードだけの差異ならコードを入れ替えれば元通りですが、新機能のために必要なライブラリをインストールしたら、そのライブラリ分が差異になります。マイグレーションを行えば、DB構成にも差異が発生します。ステージングで検証後、すみやかに本番リリースが行われるのであればこうした差異は事実上無視できますが、様々な事情で本番リリースが遅延したり、リリースが断念されてしまうこともあります。そうした際に、インストールされたライブラリや、マイグレーションによるDB構成の差異が残り続けると、今後の検証が正しく行われなくなる危険性があるでしょう。
理想的にはステージング環境は定期的に作りなおされるといいのですが、環境構築が手順書に従った手動だと大きな手間になりますので、構成管理ツールを使って自動化されているといいでしょう。
稼働時間
本番環境が24時間365日稼働していたとしても、ステージング環境が同様である必要はありません。検証を行うときだけ立ち上がっていればいいのです。オンプレなら別ですが、クラウドならば起動時間を短くすることでコストを節約できます。平日の就業時間帯だけステージング環境が起動するように設定しておくのはいいアイデアですが、リリース間近になって残業休出しているときにステージング環境が立ち上がってなくて不便ということも起こりえます。
前出の本番環境との差異を含めて考えると、構成管理ツールを使ってコマンド一発でステージング環境が新規に構築できるようになっているのが理想でしょうか。検証が終わればステージング環境を削除してしまうという運用です。
外部連携
システムは自分たちで作ったシステムだけで閉じていなくて、他のシステムと連携して動作することも多いです。他のシステムとは、自分たちで作った別のプロダクトのこともありますし、他社の提供しているサービスということもあります。
連携する他のシステムに、ステージング用のインターフェイスがあれば、それを利用すればよいでしょう。複数アカウントを取得できて、ステージング用にアカウントが分けられるのならそれでも構いません。Slack通知を行う場合、ステージング用のチャンネルを用意出来ればそちらに通知すればよいのです。
ここでも一番困るのは電子メールでしょうか。電子メールシステムは全世界に唯一しか存在しません。現実的にはテスト用のメールアドレスを用意して、そちらに配信できればテストOKとするわけですが、これでは特定のドメインへの配信に失敗するような不具合があったとしても検出できません。100万通のメールを配信する負荷テストをする場合に、同一メールアドレスに100万通配信しても負荷テストにはなりません。