[WEBサイト] 最適なステージング環境の作り方と考え方

WEBサイトの制作や、インターネットツールを開発していて、ステージング環境について、考えられているチームと考えられていないチーム、急遽作成したが故に本番環境と違っているテスト環境になっていてその不具合が多発してしまう環境。 いったいステージング環境って、どういうものが望ましいのかきちんと考えを整理してみたくなったので、まとめてみました。

ステージング環境とはどういうものか今一度理解する

ステージング環境とは、一体どういう環境をさすのでしょうか？調べてみると即座に見つかるのですが、要するに「限りなく本番に近い環境」ということです。 https://www.weblio.jp/content/ステージング環境 類似の環境として、テスト環境、検証環境、本番コピーサイト、などがありますが、呼び名はともかく、本番環境を公開前にテスト・確認するという趣旨の環境であることは間違いないようです。 とある大手開発会社では、テストも検証もステージングもすべて分けて構築しているという環境も聞いたことがありますが、これは、作業員の目的に応じて作られていてもおかしくはないですね。 一つ言えることは、開発に関わるエンジニアの人数に応じて環境も増えがちという事かもしれません。 だってもし少人数（一人とか）で開発作業を行なっている場合、複数の環境を作る事自体が無駄な場合が多いですから、確認用のステージ環境として、１つあるだけで、本番アップ前の確認が行えます。 もちろん、検証作業を外部会社に任せるために、開発員が1名でもそれ専用の環境を構築することはあると思いますが、その場合はエンジニアの数が増えると言う認識で、やはりメンバー人数に依存しますね。 もちろん、作業フローに沿って、環境を渡っていくような仕組みにしてもいいかもしれませんが、自動化できればそっちの方がいいですね。 考えなければいけないことは、全体規模ですね。

色々なステージング環境

WEBサイトの場合で、Wordpressで構築されている環境であれば、機能の中にプレビュー機能があり、特別なステージング環境を持たないというミニマムな構成もありますが、多くは、そのサイトのデータを丸ごとコピーされたものを別サーバーに構築して、本番さながらの環境を作るのが一般的でしょう。

ドメイン切り替えパターン

しかし、ここでの落とし穴は、wordpressは、データベースにサイトのURLやドメインを登録する仕組みで、テストサイトでstage.***.comのような環境を作っても、うまく動作しないという事です。 この場合は、hostsに手を加えて、同じドメインで動作するように環境を整えて利用すれば問題ないのですが、こうした切り替え作業って、非常にめんどくさく感じる事も少なくないでしょう。

下位層のディレクトリにコピー

多くの場合はサーバー毎切り分ける事も大きいのですが、同一環境で、rootディレクトリ下位にフォルダを作って、その中にモジュール一式をまんまコピーして作る環境も意外と多いのではないでしょうか？ この場合のメリットは、sslやサーバーモジュールがそのまま利用でき、本番さながらの確認が行えると言う事ですが、逆にデメリットとしては、本番のデータを汚してしまうリスクもあります。 もちろん、DBサーバーを切り替えると言う作業も必要になる場合もあり、どこまでが本番さながらなのかは疑わしいかもしれませんが、サーバー依存の事象確認はこの環境で見つけられそうです。

Dockerで構築

最近では、Dockerを使って、同一サーバーの中にポートを分けてシステムを作ってしまうという事もできるかもしれませんが、Dockerを本番運用させるぐらいならAWSなどのクラウドサーバーを使った方が確実かもしれませんね。 AWS内のEC2にDockerを仕込んで複数環境を実現させているものも見た事ありますが、きっとサーバーエンジニアがやりたいようにやっちゃったパターンでしょうね。

理想の環境についての思考

理想の環境でコレ！というのは、なかなか１つに絞り込めませんんが、以下の概念は共通して考えられます。

1. コピーしてまんま使えるディレクトリ構成。

本番環境との切り替え作業が限りなく少ない
ステージング環境が存在して、確認を行ったとしても、本番環境で不具合発生する場合があります。
これは、ステージング環境と本番環境の差分がどの程度あるかという事ですが、そもそも、apacheやnginxの設定が違っていて、動作が変わっていたとか、ディレクトリ構造が若干違っていて、モジュールパスが変わってしまったなど、お寒いですが、比較的多い原因のようです。

2. 絶対パスと相対パスをきちんと使い分ける。

サイトやサービス全体が、相対パスで実現されている。
HTMLソースに記述するモジュール読み込みなどのパスが、 URLで書かれている場合は、ステージングでありながら、実は本番モジュールを読み込んでしまっていて、ステージングが機能しないとか、本番との差分が発生してしまう原因になります。
また、API読み込みなどで専用ステージングに対応するAPIを保持している場合なども、本番化する場合に、内容を切り替えてアップロードしなければ、エラーが発生してしまいます。
このアップロード手順による不具合は、舐めているととんでもない不具合につながります。

3. 環境の再現性を考慮する。

できるだけ特殊な環境のライブラリなどを導入しないという思考は、そんなに難しくないと思います。 どのライブラリが良くて、どれが悪いかという事ではなく、WEBサイトやサービスの環境構築をする時に、インストールや設定などが稀な環境を作ってしまうと、環境コピーで不具合が発生してしまい、結果的に、違った挙動をしてしまってステージングになり得ないという事もすくなくありません。 再現性を重要視する考え方は、環境構築に置いて必須だと考えられます。