序
今までシステム開発に携わってきて考えた事。開発時に使用する環境から、リリース対象となる最終的な実運用環境まで、用意すべき環境についての私案です。
ウェブ開発で大切な3つの環境: 開発・ステージング・プロダクションというQiitaの記事を見つけました。開発とステージングと本番の3つの環境を用意しよう、というのは割とよく見る意見です。ある程度以上のプロジェクトだと、実際にこの3つを用意するのが普通でしょう。ただ、私が思うに、3つではちょっと足りない気がしています。
開発環境（ローカル環境）
上述のQiita記事 ウェブ開発で大切な3つの環境: 開発・ステージング・プロダクション では「開発環境は開発者によるテスト環境」と書かれていますが、一般的には、「開発者が自由に使えるローカル環境」を指す事が多いのではないでしょうか。
開発者が自由に使えるというのは、本当に文字通りです。下記のような条件を満たす環境を開発者ごとに用意して、ローカルとして通常の開発に使用します。
- 他の開発者と干渉しない
- 仮に再起不能なほど壊しても、誰にも迷惑を掛けない
ここで少々厄介なのがデータベースとハードウェア。
データベースを人数分用意する事は、用途を開発に絞ってしまえばそれほど大事ではありません。問題は、すべての開発者が同一の設定で別々のデータベースにアクセスできる仕組ですね。一工夫が必要ですが、やってやれない事もありません。ただ、テーブルスキーマの変更などがあった場合に全員で同期する段取りを用意するのがちょっと大変です。
そしてハードウェア。私はWeb系よりビジネス系のシステムに携わる事が多かったのでそちらを想定するのですが、例えば印刷機能があります。帳票印刷などビジネス系の基本中の基本。当然、プリンタを好きな時に好きなだけ使う必要があります。しかし開発者ごとに実際にプリンタを用意するのは非常に難しい。ただ、これも工夫は出来ます。最初にきちんと検討しておけば何とかなります。
検証環境（テスト環境）
どんなテスト環境を用意するかは工程の設計とも関わってきます。テストの何たるかについては、テストに関する理論を調べて下さい。
余談ですが、テストというと見下す技術者や顧客も時々いますけども、テスト専門の会社が存在するほど奥が深くてノウハウの必要な分野です。アメリカなんかだと仕様に関するコンサルティングまで業務範囲に入っているゲームのテストの専門会社もあるとか。それでなくても、品質管理においてテストは決して軽視できる分野ではありません。
…という知識を踏まえて、テストの為にどんな環境を用意すべきか。
単体テストに関しては、開発環境で済ませてしまうのが一般的だと思います。単体テストに必要なデータの用意が簡単なので。運用ルールで禁止されるけれども理論上は可能性を否定できないデータの組合せとか、そういう状況下でのテストをするには、どれだけ想定外の状況を用意しても誰にも迷惑を掛けない開発環境が最適なのです。また単体テストは開発者自身が実施するのが一般的なので、その点でも開発環境での単体テストは自然です。
問題は結合テストです。結合テストに関しては専用の環境を用意した方が良いでしょう。贅沢を言えば、テストメンバーの人数分だけ用意したい所です。まぁ結合テストならば、作業範囲を区切ってスケジュールを調整すれば、環境1つでやりくり出来る事が多いでしょう。
またテストを自動化する際にも、その為の独立したサーバが必要となります。
ステージング環境
ステージングの意味等については、上述のQiita記事 ウェブ開発で大切な3つの環境: 開発・ステージング・プロダクション を参照して下さい。大事な用語を丸投げでナンですけど
デモ環境とかレビュー環境とか言えばイメージは近い…かな？基本的にバグは取り切っていて、上司や顧客の最終確認の場になります。本番に近いデータを用意する事になりますが、機能確認の為に本番通りではないデータが仕込まれる可能性もあります。
リハーサル環境
文字通り、リハーサルをする環境です。本番と全く同じ環境を用意して、本番と同じ状況で実行します。
特にシステム移行では重要視される工程です。但し私の経験上、普通のデバッグを含むリリース時にも、リハーサルを実施した方が良いような気がしています。せめてデータだけでも本番と全く同じものを使ってテストしていれば防げた事故というのが、たまに発生します。
ただ、本番データを流用するとなると、権限の関係でなかなか難しい事も多い。個人情報や企業秘密が絡んでくると、開発者やテスターの誰も彼もが自由に閲覧する訳にもいきません。そこが難しい所で、ある程度の妥協が必要になる点でもあります。
更に言えば、外部との連携機能を搭載している場合には一工夫の必要があります。
- 機能実行終了時にメール通知が発生する場合。本番と全く同じデータという事は、メールの宛先も本番と同じという事で…運用担当者だけならまだしも、大量の一般ユーザに不審なメールが届いてしまったら…
- FTP等々で外部のサーバにデータを転送する場合。設定も本番と同じだと、リハーサルのデータが外部の本番サーバに転送されてしまいます。気が遠くなるほど後始末が大変です。
こういうのは普通に大事故です。そうならないように、ネットワークの設定をいじるなどで対応しておく必要があります。
本番環境（プロダクション環境）
言わずと知れた、サービス提供の実運用を行う環境です。
本番環境は開発者ではなくて、システムを発注したお客様の所有物です。その上のデータは、開発者ではなくてお客様の財産です。うっかりミスでデータを改変してしまったなんてのは論外。データのコピーも慎重にやらなければなりません。リハーサル環境でも触れましたが、実は、下手すると契約にまで関わってくる大変な話だったりします。
そういう訳でなので、本番環境にアクセスできるメンバーは、かなり厳密にコントロールする必要があります。
結
以上、可能であれば用意しておきたい環境を、私の経験から考察して列挙してみました。
- 開発環境
- 検証環境
- ステージング環境
- リハーサル環境
- 本番環境
5種類ですね。昔はハードウェアを個別に用意する必要があったのでコストや設置場所が大変でしたが、最近は仮想環境の出現で非常に楽になりました。超軽量仮想環境も出現している昨今、少なくともLinuxに関しては渋る理由は薄くなったと言えるでしょう。個人の趣味プログラミングでも用意できるレベルです。