Day 7・チーム開発の作法 — 規約・Gitフロー・レビュー・テスト・秘匿情報
.envと秘匿情報 — 設定と鍵の扱い方
環境ごとの設定と秘密の分離、config()経由で読む理由、マイグレーション共有。
秘匿情報をコードに書いてはいけない
DBのパスワード、外部APIのキー、暗号化の鍵といった秘匿情報を、ソースコードに直接書いてGitに入れると、リポジトリを見た全員に鍵が漏れます。これを避けるため、そうした値は ファイル(.env)に切り出し、Gitの管理対象から外します。
.env はコミットしない
.env には本番のパスワードや鍵が入るため、.gitignoreで除外して絶対にコミットしません。代わりに、鍵の値を伏せた「.env.example」をコミットし、『どんな設定項目が必要か』だけをチームで共有します。
環境ごとに値を変える
開発・ステージング・本番では、接続先DBもAPIキーも異なります。コードは同じまま、.envの値だけを環境ごとに差し替えることで、1つのコードベースをどの環境でも動かせます。
APP_ENV=production
APP_DEBUG=false
DB_HOST=127.0.0.1
DB_DATABASE=shop
DB_USERNAME=shop_user
DB_PASSWORD=ここに本番のパスワード
STRIPE_SECRET=sk_live_xxxxxxxxxxxxAPP_ENV=local
APP_DEBUG=true
DB_HOST=127.0.0.1
DB_DATABASE=
DB_USERNAME=
DB_PASSWORD=
STRIPE_SECRET=config() 経由で読む理由
コードから直接 env() を呼ぶ
// アプリのあちこちで env() を直接呼ぶ
$key = env('STRIPE_SECRET');
// 本番では設定キャッシュ時に env() が null を返し、事故になるconfig() 経由で読む
// config/services.php で一度だけ env() を読み、キーを定義
// 'stripe' => ['secret' => env('STRIPE_SECRET')]
// アプリ側は config() を使う
$key = config('services.stripe.secret');なぜ config() を挟むのか
Laravelは本番で「config:cache」により設定を1ファイルにまとめて高速化します。このとき env() はキャッシュ後にnullを返すため、コードから直接env()を呼ぶと本番で値が消えます。config()経由なら、設定はconfigファイルで一度だけenv()を読み、以後はキャッシュされた値を使うので安全かつ高速です。設定の入口を一箇所にまとめる意味もあります。
マイグレーションで構造を共有する
秘匿情報は共有しませんが、DBの『構造』はチームで共有する必要があります。 は、テーブルの作成・変更をPHPコードで記述し、Gitで共有する仕組みです。各自が同じマイグレーションを実行すれば、全員のDBが同じ構造になります。初期データが必要なら を併用します。
# 最新のマイグレーションを適用してテーブルを作る/更新する
php artisan migrate
# 開発用の初期データを投入する
php artisan db:seed何を共有し、何を隠すか
共有するのは『構造(マイグレーション)』『必要な設定項目の一覧(.env.example)』。隠すのは『実際の鍵やパスワード(.env)』。この線引きが、チームで安全に同じ環境を再現する鍵です。
面接ではこう言う
「鍵やパスワードはコードに書かず.envに切り出し、.gitignoreで除外します。共有するのは項目だけを示す.env.exampleです。アプリからはenv()を直接呼ばずconfig()経由で読みます。本番の設定キャッシュ後にenv()がnullを返す事故を避けるためです。DBの構造はマイグレーションで共有し、初期データはシーダーで揃えます」
読んでも腑に落ちない所は、AIに噛み砕いてもらいましょう。
理解度チェック
答えられれば、面接で説明できる状態に一歩近づきます。
.env ファイルを .gitignore で除外する理由は?
アプリのコードから env() を直接呼ばず、config() 経由で読むべき理由は?
チーム開発で『何を共有し、何を隠すか』を、.envとマイグレーションの観点で説明してください。
記述式です。まず自分の言葉で答えを考えてから、模範解答を開いて自己採点してください。