Fixtureによるマスタデータの管理とDBIx::Fixture::Adminについて
この記事は、Perl 5 Advent Calendarの19日目の記事です。
19日目はid:meru_akimboです。
マスタデータの管理
RDBSを使ったWebアプリケーションのマスタデータの管理にはいろいろとやり方があります。
ざっと思いつくものでは、
- 管理用のWebアプリケーションからformを使う
- xlsやcsv、yaml(以下そういう系のファイルをFixtureと呼びます)をデプロイして流しこむ
- 都度DBにログインして直接SQLを発行する(!?)
最後の一つ以外は実際に運用したことがあります。
今回は2つめのやり方の利点について掘り下げます。
Fixtureを用いて管理することの利点
- マスタデータのバージョン管理が可能になる
- マスタデータのテストが可能になる
- 開発環境のマスタデータを本番と同じものにできる
といった点が挙げられます。
マスタデータのバージョン管理
マスタデータもコードと同様にリポジトリに配置し、バージョン管理することで、より安全で効率的にアプリケーションを運用することができます。長くアプリケーションを運用していると、過去のデータを振り返ったときに今のマスタデータが果たして意図している状態なのかわからなくなったりがちです。
バージョン管理下におくことである程度データの変更意図を追いやすくなります。
また、リポジトリに置かれていないFixtureの反映を不可能にすることで、反映すべきでないデータがうっかり投入されることを防ぎやすくなります*1
マスタデータのテスト
マスタデータもコードと同様にテストが書かれていることが望ましいでしょう。
これに関しては一昨年のAdvent Calendarの記事が詳しいのでそちらのリンクを置いておきます。
開発環境のマスタデータを本番と同じものにできる
開発環境で本番と違うデータを使って機能開発やデバッグをしていると、本番とのデータの差異のせいで不具合が再現できなかたり、再現させるために非常に手間がかかることがあります。
毎度DBのdumpをとってもいいのですが、Fixtureを介してマスタデータを扱うことで、比較的容易に本番と同じマスタデータを用意することができます。
以上のような利点から、最近関わっているプロジェクトではだいたいFixtureを使ったマスタデータの管理を行っています。
DBIx::Fixture::Adminについて
Fixtureの扱うための処理をDBIx::FixtureLoaderなどを使って毎度書いているのですが、
何度も書くのはｱﾚですし、汎用的な形ですぐに使えるものが見当たらないので、暇を見て書いています。
carton installしてプロジェクト配下に設定ファイルを置けば、すぐに コマンドを叩いてFixtureの生成や流しこみを行える形を一応考えています。
ユーザデータ用のテーブルだったり、やんごとなき事情でFixtureで管理できないテーブルなども存在するはずなので、ignoreするテーブルを正規表現で指定可能にしたりなどを細々とした機能もつけています。
実装の進捗としては、とりあえずignoreを考慮したyamlのFixtureを流す部分と、生成する部分のテストが通ったくらいです。コマンドラインツールと設定ファイル扱う部分ができればとりあえず使えるかなと思います。
現状yamlしか使えない状態なのですが、csvも扱えるようにしてFixtureを直接編集しやすくするようにも早めにしたいところです。
Test::Fixture::DBIのyamlはDBのデータから生成したものをちょっと修正するのはともかく、一から手で書くのは大変ですし、開発者以外も触ることを考えるとexcelやGoogleスプレッドシートで直接編集できたほうが便利なので。
20日目はid:kfly8さんです。
*1:管理用webアプリケーションへのアップロードなどで反映を行っていると起きがち
