運用後DB変更
LivingDBMigration
長いまえおき
運用後DB変更は、生きているDB(LivingDB)に対してDB変更(DBMigration)をするということで、運用前の開発時点とはうってかわって神経質になることが多くなります。 当然、たっぷりと価値の高い業務データが既にDBに登録されているため、DBを一から作り直して反映させるというようなことはできません。 一番最初の本番スキーマ作成を除いて、DBFlute の ReplaceSchema を本番環境に適用させることはありません。
本番環境には差分DDL(alter文など)を適用する必要があります。差分DDLはERDツールから自動生成するか、手動で作成する必要があります。 一方で、新しいメンバーの開発環境や、新しいテスト環境などの構築のために、フルDDLも必要となります。そもそも開発環境では ReplaceSchema を大いに活用して運用後も(運用後こそ)テストデータ管理を徹底していきたいものです。
ただ、差分DDLはこれはこれでしっかりと検証をしなくてはなりません。手動作成のものはもちろん、ツールから自動生成した場合でもぶっつけ本番は避けたいものです。 結合テスト環境などでの適用も考えられますが、結合テスト環境自体を ReplaceSchema 管理にする場合もありますし、そもそももっと前のタイミングで検証したいものです。
と考えていくと、やはり煩わしい作業なしではなかなかフルDDLと差分DDLの整合性を保つことはできません。 気をつけていればほとんどの場合は大丈夫とはいえ、運用後の開発というのは一つ一つの期間が短くリスクも高い、 そのわりには長く繰り返し続いていくもので、できれば安全度を高めて精神的負担も少なくしたいところです。
DBFluteのアプローチ
DBFluteでは、生きているDBに対するDB変更(LivingDBMigration) を支援する機能にアプローチしています。この領域は環境依存が強く多種多様なため、仕組みで完全なレールを敷くことはなかなかできませんが、 少しでも運用後の業務の安全性とスピードを確保することができればと。
- AlterCheck
- 差分DDL(AlterDDL)とフルDDL(NewDDL)との整合性チェック
