.envと環境変数の扱い、設定をコードに埋め込まない

.envと環境変数とは、DBのパスワードやAPIキーといった設定をコードから切り離して外部に持たせる仕組みです。ローカルでは .env ファイル、本番ではサーバの環境変数で渡すのが定番です。

接続情報をソースに直書きしない

DBのパスワードやAPIキーをソースに直書きすると、リポジトリに秘密が残るうえ、環境ごとに書き換えるはめになります。設定はコードから切り離して環境変数に持たせる、というのが基本方針ですね。ローカルでは .env ファイルに書いておき、本番ではサーバの環境変数で渡す、と使い分けるのが定番だと思います。

# .env(コミットしない)
DB_HOST=localhost
DB_PASS=secret
APP_DEBUG=true

.envはコミットしない、雛形だけ置く

肝心なのは .env を .gitignore に入れておくことです。その代わり、何のキーが必要かを示す .env.example を値なしでコミットしておくと、他の人が環境を組むときに迷いません。「秘密は入れない、必要なキーの一覧は共有する」の両立ですね。

# .gitignore
.env

# .env.example(値は空、これはコミットする)
DB_HOST=
DB_PASS=
APP_DEBUG=

getenvの戻り値は文字列、が落とし穴

読み出しは getenv() や、vlucas/phpdotenv などを使うと $_ENV 経由でも取れます。ここで引っかかりやすいのが、環境変数は常に文字列で入ってくる点です。APP_DEBUG=false と書いても、getenv で来るのは文字列の “false” なので、そのまま if にかけると true 扱いになってしまいます。型変換を一枚かませておくのが安全ですね。

$debug = getenv('APP_DEBUG'); // 文字列 "false"

if ($debug) { /* "false" は真になってしまう */ }

// 明示的に真偽へ変換する
$debug = filter_var(getenv('APP_DEBUG'), FILTER_VALIDATE_BOOL);
$port  = (int) (getenv('DB_PORT') ?: 3306);

まとめ

設定はコードに埋めず環境変数へ、.env はコミットせず example だけ共有、という運用にしておくと、環境の切り替えも秘密の管理もずっと楽になります。あとは getenv の戻り値が文字列である点だけ意識して、真偽値や数値は明示的に変換しておくと事故が減る気がします。私はこの型変換を一度ハマってから、設定を読む薄い関数にまとめて通すようにしています。

よくある質問

Q. .env ファイルはリポジトリにコミットすべきですか?
A. いいえ、秘密が残るので .gitignore に入れます。代わりに必要なキーだけを値なしで並べた .env.example をコミットして、他の人が環境を組めるようにします。

Q. APP_DEBUG=false と書いたのに true 扱いされます。
A. 環境変数は常に文字列で入るため、”false” という非空文字列が真になっています。filter_var で FILTER_VALIDATE_BOOL を使うなど、明示的に型変換しておくと安全です。