ReplaceSchemaタスク

Alto DBFlute のパートです。

Alto DBFlute

ReplaceSchemaタスクとは？
実行コマンド
環境構築
- ReplaceSchemaへの移行
処理概要
運用後のDB変更
補足

ReplaceSchemaタスクとは？

DBスキーマの(再)構築を自動化するDBFluteタスクです。

スキーマ作成(初期化)・データ登録・データ整合性チェック というプロセスを自動化します。

ReplaceSchemaタスクの概念図

図 : ReplaceSchemaタスクの概念図

利用するメリット

DBの初期構築や再構築の自動化、統一化: DBFlute(ReplaceSchema)を使っているプロジェクトであれば、どこにいっても ReplaceSchema を実行することでテーブルが作成され、テストデータも一気に登録。 DB変更の開発環境への反映も、Subversion から最新状態を更新して ReplaceSchema すればDBもテストデータも最新に。再構築の初期化時はFK制約も考慮してテーブルが drop されるため、遠慮なくFK制約のメリットを享受できます。; 独自の仕組みになりがちなDB構築処理、これを統一化することで新加入のディベロッパーの開発環境構築もスムーズに。.NETプロジェクトでも DBFlute.NET を利用していれば、Javaプロジェクトと.NETプロジェクトでメンバーが行き来しても迷うことはないでしょう。
テストデータの一元管理、ディベロッパー間での再利用: DB変更の影響はプログラムではなく、テストデータも大きく影響します。分散されて定義が冗長していると、テストデータの修正だけで大きなコストとなってしまいます。また、一元化されていても insert 文ではカラム追加もままなりません。 ReplaceSchemaはDB変更に強いテストデータ管理 を提案します。
テストデータについて; マスタデータに限らず、トランザクション系のテストデータをしっかりと一元管理することが大事です。 DBAの目の届かない領域にある不整合なデータでテストされてもあまり効率的ではありません。; また、プログラムは懸命に再利用を考慮していても、各ディベロッパーが同じようなテストデータを作成してバラバラに管理していたら片手落ちです。 テストデータ自体も共有して再利用することで作成コストを抑えて、DB変更時のテストデータへの影響範囲を小さくすることが大事です。
再現可能なテストデータ: そして、いつでもテストデータを基底となる元の状態に戻すことができるのも大事です。どれだけDB上でアプリ上でデータをいじっても、データを壊しても、 ReplaceSchema を実行すればすぐにもとの状態に戻すことができる。また、他の人と同じ状態のテストデータをすぐに(ローカルDBなどで)再現できる。; ReplaceSchema は、テストデータを再現可能な状態として残していくという概念を提供します。
テストデータの品質の維持: さんざんデバッグしたあげく、結局のところ原因はテストデータが変だった。珍しい話ではありません。; 例えば、正式会員だけであればメールアドレスがユニークになる、という業務的制約があるとします。これは DBMS の制約としてはチェックできないもので、当然アプリでそうならないように制御するわけですが、 テストデータを作成するときも不整合なデータを作らないように気をつける必要があります。しかしながら、アプリの実装のときに比べてその意識はどうしても低くなりがちで、そして、ケアレスミスでできた不整合なデータでテストしても、そのテストは有効なものではありません。; ReplaceSchemaではテストデータの業務的な制約をチェックするための枠組みが用意されています。できる限りテストデータ不備によるディベロッパーの余計なコストを払わないようにしたいものです。
しっかりとログに残る: ログをしっかり残していることが意外に重要です。軽く見られがちなDB構築処理、スクリプトなどで手早く独自に実装されがちですが、DDLの実行やテストデータの登録など、ケアレスミスの発生しやすい領域です。しっかりと不正なDDL、不整合なテストデータのデバッグがしやすい環境になっていることが大事です。自分自身でのデバッグはもちろん、DDL作成者、テストデータ作成者などに発生したエラーを相談するときなど、しっかりとトレースされているログがものを言います。それを独自の実装でやろうとすると意外にコストが掛かるもの、"DB環境構築処理の実装" にたっぷり時間をくれるマネージャはなかなかいません。