ステージング環境は、開発した変更を本番へ出す直前に、本番そっくりの条件で最終確認するための環境です。 開発の流れでは「開発環境 → ステージング → 本番」という3層が基本形になります。
3つの環境の役割分担
| 環境 | 目的 | データ |
|---|---|---|
| 開発環境 | 作る・壊す・試す | ダミーデータ |
| ステージング | 本番相当での最終確認 | 本番相当（要マスキング） |
| 本番環境 | 利用者が使う | 実データ |
「本番と同じ」はどこまで必要か
ステージングの価値は本番との近さで決まりますが、完全一致はコストが高く、何を近づけるかの選択が設計です。
- OS・ミドルウェア・PHP等のバージョン … 必ず揃える（ここのズレは「ステージングでは動いた」の主因）
- データ量 … できるだけ近づける。10件のテーブルと100万件のテーブルでは、同じSQLでも挙動が別物
- 外部連携 … 決済・メール送信はテスト用の窓口（サンドボックス）に差し替える。本物につないだままだと確認作業が実注文・実メールになる
本番データをコピーするときの注意
本番DBをそのまま持ってくると、個人情報がステージングに複製されます。ステージングは本番より守りが緩いことが多いため、氏名・メール等を機械的に置き換えるマスキングをコピー手順に組み込むのが原則です。
押さえておきたい注意点
- ステージングで確認するのは「手順とロジックが正しいか」。本番のいまのデータに対して安全かは、実行直前の dry run で別途確かめる（DBのdry runとは）
- レンタルサーバーやWordPressの「ステージング機能」も同じ考え方のボタン化。そちらの文脈はステージングの項を参照