サービスを提供する上で、テスト環境というのは重要な環境である。
リリース後いざ運用を開始してみると、バグ修正・機能追加・仕様変更はかなりの頻度で発生する。
ここでは表でエンドユーザにサービスを提供している環境を「本番環境」、バグ修正・機能追加を行い、裏で試験する環境を「テスト環境」と呼ぶことにする。
当然「本番環境」では安易に修正を行って障害を発生させることは許されない。
ルールとして、バグ修正・機能追加を行う場合は必ず「テスト環境」で動作確認を実施し、正しく動作する場合のみ「本番環境」に修正版ソースを適用することで障害発生の確率を大幅に下げることができる。
これはどの現場でも日常的に行われていることだろう。
そこで起こりやすい障害の1つに「テスト環境」に適用すべきソースを「本番環境」にあててしまうケース。
アプリケーションを構成するほとんどのソースがテスト環境と本番環境で同じだが、一部の設定ファイルだけ差異があるというような構成の場合である。
間違えが起こらないよう、設定ファイルもテスト環境と本番環境で同一にしたい。
この課題がクリアできれば前述のようなしょうもない障害を防げる。
下記はその例である。
テスト環境を「test.example.com」、本番環境を「example.com」とする
/**
* 本番環境とテスト環境で差異のある設定値を動的設定する
*/
// Apache から呼ばれた場合
$server_name = isset($_SERVER['SERVER_NAME']) ? $_SERVER['SERVER_NAME'] : '';
// CLI から呼ばれた場合
$hostname = isset($_SERVER['HOSTNAME']) ? $_SERVER['HOSTNAME'] : '';
// Mail から呼ばれた場合
$host = isset($_SERVER['HOST']) ? $_SERVER['HOST'] : '';
// CRON から呼ばれた場合
if ($server_name == '' && $hostname == '' && $host == '') {
$hostname = exec('hostname');
}
// テスト環境の設定
if (strpos($server_name, 'test.') === 0 || strpos($hostname, 'test.') === 0 || strpos($host, 'test.') === 0) {
$DOMAIN_NAME = 'test.example.com';
$MAIL_DOMAIN = 'test.example.com';
$DB_HOST_1 = 'test.db1.example.com';
$DB_HOST_2 = 'test.db2.example.com';
// 本番環境の設定
} else {
$DOMAIN_NAME = 'example.com';
$MAIL_DOMAIN = 'example.com';
$DB_HOST_1 = 'db1.example.com';
$DB_HOST_2 = 'db2.example.com';
}
// 定数を動的設定する
define('DOMAIN_NAME', $DOMAIN_NAME);
define('MAIL_DOMAIN', $MAIL_DOMAIN);
define('DB_HOST_1', $DB_HOST_1);
define('DB_HOST_2', $DB_HOST_2);
下記の情報を元に環境別に違いがでる変数を比較している。