本番のコピーより、シードで作ったサンドボックス
ローカル環境はまるごと、プロセス内で動く Postgres です。空の状態から起動し、本物のマイグレーションを適用し、それらしい架空のサロンのデータで自分を満たします。ノートPCに本番の認証情報はなく、スクリーンショットに実在のお客様のデータも写らず、デモが古びることもありません。
小さなチームにはいつか、ローカル開発を本番データベースのコピーに向けたらどうか、と誰かが言い出す瞬間が訪れます。架空のデータは薄っぺらく感じるし、本当のバグは本物のレコードでしか起きない、というわけです。魅力的な考えですが、後を引く後悔がついてきます。認証情報がノートPCに広がり、スクリーンショットにお客様の名前が写り、テスト用のメール送信がある日ほんものの宛先を見つけます。私たちは逆の道を選び、一度も振り返っていません。
プロセスの中にまるごと Postgres
組み込み Postgres は本当に出来がよくなりました。私たちのアプリは起動時に判断します。環境に本物のデータベース認証情報があればホストされたデータベースを使い、空ならローカルのフォルダに置かれたプロセス内 Postgres を立ち上げます。開発マシンにはそもそも認証情報がないので、設定を間違えたノートPCで起きる最悪の事態は、まっさらな空のデータベースであって、本番障害ではありません。
// Choose the database at runtime. Blank env = embedded, local, harmless.function makeDb() { const url = process.env.DATABASE_URL; if (url) return connectHosted(url); // In-process Postgres persisted to a local folder const client = new EmbeddedPostgres('./.pgdata'); return drizzle(client, { schema });}作り直しの手順は、エンジンと同じくらい大事です。ローカルのデータベースは、本番が実行したのと同じマイグレーションファイルを、最初の1本から順番に適用して再構築します。この一つの決定だけで、ひと通りのバグが手間なく見つかるようになりました。あとのファイルにある列を前提にしていたマイグレーション、古いスナップショットには当たるのにゼロからでは通らないスキーマ変更。ノートPCで履歴からスキーマを組み立てられないなら、次のデプロイでも組み立てられません。
行ではなく、事業をシードする
役に立たない架空データと役に立つ架空データを分けるのは、物語があるかどうかです。私たちのシードスクリプトは、test という名前のユーザーを10人入れたりはしません。名前のあるサロン、得意分野を持つスタッフ、現実的な料金と所要時間のメニュー、来店履歴のあるお客様、これからの予約、在庫数と入出庫の記録がある物販商品を作ります。画面に人の気配があるので、レイアウトの崩れ、空の状態の見え方、不格好な文字の切れ方が、実際のお客様が見るのと同じように表に出てきます。
この性質は見過ごされがちです。ドキュメント、ブログ、バグ報告に載せているスクリーンショットは、すべてシードしたサンドボックスから撮っています。お客様の名前が紛れ込んでいないかと画像を目を細めて確かめる必要はありません。紛れ込む名前がそもそも存在しないからです。いちばん安全な黒塗り作業は、黒塗りするものが何もないことです。
押さえておきたいこと
- 安全な道をはじめから既定にします。実データに触れるほうにこそ手間がかかるべきで、避けるほうに手間をかけさせてはいけません。
- 副作用も無効にします。メール、決済、ストレージのキーはローカルでは空のままにして、シードしたお客様をループで回しても実在の人に連絡が飛ばないようにします。
- 怖い状態こそシードします。作りたての新規アカウント、予約で埋まった一日、在庫切れの商品、何年も前に一度だけ来店したお客様。
- シードもコードレビューの対象にします。機能がテーブルを増やしたらシードも一緒に育てないと、サンドボックスは静かに腐っていきます。
効果は積み重なります。新しく入った仲間は、コマンドを二つ実行するだけで、触って試せる事業が手元にできます。ビジュアルQAはプライバシー審査なしにどのページでも撮影できます。そしてデモ環境は、いつでも5分で新品同様に戻せます。新品同様とは、作り直すだけのことだからです。
本番のデータは疑問に答えてくれます。シードしたデータは、安心して疑問を投げかけさせてくれます。
