複数環境でPHPを動かすときに気をつけていること。

PHP

ほとんどのサーバー再度開発は　Local→ステージング→本番の様に　コーディングからリリースまでに複数の環境で動かすことが多いと思います。

この時に問題になるのが"Localでの環境設定がそのまま本番にUPされてしまった。"といった環境依存コードの管理ではないでしょうか？

今回自分が環境依存コードの管理で気をつけている事をまとめてみました。

1. 環境の設定をSCMに入れない。

subversionやgitにどの環境を判定・設定するコードを入れずに、サーバーの設定や、デプロイ時のコマンドで対応するようにします。

下記の様なコードをSCMに上げていると"Localの環境が本番に上がってた。"　といった危険が増えます。

#本番では下をコメントアウトする。
define(DEBUG, true);


上記を防ぐために環境切り替えのためのコードはSCMで管理している場所以外に置くようにします。

よく使う場所としてはApacheのconfです。


<localhost *:80>
...
SetEnv APP_ENV development
...
</localhost>

上記で設定した環境変数はPHPではgetenv関数で取得する事が可能です。


$env = getenv('APP_ENV');

switch($env) {
    case: 'production'
        include('prod_conf.php');
        break;
    case: 'development'
        include('dev_conf.php');
        break;
    case: 'test'
        include('test_conf.php');
        break;
}


上記の様な工夫により環境の設定ミスを起こす可能性がかなり減らせます。

2. 非機能要件は抽象化する。

非機能要件→キャッシュ、ログ、セキュリティなどは必ず何らかのラッパーを入れて
環境により切り替えられるようにしないと、「テストのためだけにコメントアウトしたコードが本番に上がる」
といった事態が起こります。


//windows環境で動かせないので下をコメント（といった一時的なコードがそのまま本番に上がってしまう。）
// $settings = $memcache->get('setting');


SymfonyやSpringなど、DIコンテナが使えるのであればそれを使ってキャッシュやログ管理を抽象化するようにしましょう。
そういったものが使えない場合もライブラリを導入するか自作するかして、他のプログラマが、キャッシュ機構やログ機構を意識しないような設計にするのは重要です。

以上です。
こういうのはユニットテストなんかを書くと早めに気づけるので、テストコードを書きつつ設計を見直すことをおすすめします。