Jiemamyってなんぞ(4) - コミットは、DB構成の同期も取って
大抵、アプリケーション開発では、SCM*1を使って、変更履歴を管理する。この構成管理のメリットは色々あるけど、代表的なのはこんなもんかな。
- いつ, 誰が, どこを, どのように, （なぜ*2）変更したのかを管理できる。
- アプリケーションの動作に必要なファイル群をひとまとめにできる。
- 何かトラブルがあった時など、過去の状態をいつでも呼び戻せる。
ここで2について。プロジェクトによっては、テストコードはコミットしない、データファイル・設定ファイルはコミットしない、ドキュメントやDBのCREATE文はファイルサーバに置いて管理する、などの不思議なルールがまかり通っています。果たして、これらのファイルを構成管理下に置かないメリットはあるのか。否。
これらのファイルを構成管理したがらない人が主張するのは「関係ないファイルを置きたくない」「置いても管理できない」等かな。設定ファイルやドキュメントは果たして「関係ないファイル」なのか。構成管理システム下に置かない事で「管理できるようになる」のか。今一度考えて頂きたいところです。
これは、そもそものプロジェクトディレクトリ構成の作り方が間違ってるんじゃないかなー、と思ってます。分かりやすいように*3EclipseでのWebアプリケーションプロジェクトを想像してみる。プロジェクトの直下がWebのコンテキストルートだったりしませんか？ プロジェクト直下にWEB-INFがある感じ。
そりゃ、そういうディレクトリ構成のプロジェクトにSQLファイルとかコミットしたく無くなる気持ちも分かる。意識しなければwarに一緒にパッケージングされてしまうし、それだけ敢えて除外するのもコストがかかる。だからMaven構成好きなんですよ、俺ｗ ちゃんとディレクトリが整理されてる。この構成だったら、src/document というディレクトリを作っても良いと思えます。
Mavenのディレクトリ構成は…。いや、これ以上話を逸らすのやめて別エントリにしますｗ
でだ。例えばDB構成情報であるSQLファイルをファイルサーバで別管理してたらどうなりますか。3のメリットが消滅します。WebアプリはDB構成に依存しますので、ソースコードだけ過去の状態に戻せたとしても、当時はどんなスキーマだったんだろうか。その時のDB構成情報が呼び戻せません。
まぁ、さすがにタグを切ったタイミングでのDB構成情報くらいは残していると思いますが、そんな荒い粒度ではなく、コミット単位で構成情報の変更を追跡できるようにすべきだと思います。
上記がきちんと行われないもう一つの理由は、SQLのマージが困難だから、じゃないでしょうか。リファクタリングの困難性と通じるものがあると感じます。
そこで地豆ですよ
Jiemamy Projectでは、JiemamyモデルファイルをSVNにコミットすることを推奨しています。これにより、DB構成情報をSVNのコミット単位で管理できるようになる。
さらにJiemamyモデルファイルは、マージ容易性を考慮したXML*4になっています。つまり、万一他のメンバと変更が重なっても、比較的楽にマージできるようになっています。前回お話したER図のデータファイルなんかは、下手するとバイナリファイルですから、その時点でマージは断念。
普段はER図エディタでお絵かきする編集だけで済みます。が、いざとなればXMLの直接編集による変更も可能なのがJiemamy。慣れてくれば、小さな変更ならばER図エディタを立ち上げず、XMLを直接修正した方が楽なくらいです。
データも管理
Webアプリケーションによっては、初期マスタ等、初回起動時に既にテーブルにデータがINSERTされている必要があったりします。例えば、まずログインしないと始まらないアプリだったら。初期状態でadminアカウントくらいは登録しておかないと何もできませんね。
Jiemamyモデルでは、この「テーブルにINSERTするデータ」も同時に管理します*5。さらに、「データセット」として、複数の「INSERTするデータの組み合わせ」を管理することもできます。
例えばそのアプリに「Standard版」「Professional版」なんかがあったとして、とあるテーブルの値によって動作が変わる、なんてケース。この場合は、2つのデータセットを作って、それぞれに別のINSERTデータを保存しておけばOK。
また、アプリケーションのテストなんかにも応用できます。
- 検索結果が0件だった場合「検索結果はありません」と表示される。
- 検索結果が1〜99件だった場合、それぞれの結果を表示する。
- 検索結果が100件以上だった場合、「条件を追加して絞り込んでください」と表示される。
なんてテストがあったとき。検索結果数はDBの状態に依存しますので、毎度毎度色々なデータをTRUNCATEしてはINSERTして…、ってをやらなきゃいけない。めんどくさい。外部キーで参照されてた日にゃ、データ総入れ替えですよ。
そんなときも、データセットを使えば良いです。このテスト用のデータセットぶっこめー。テストしたー。次のデータセットー。と、テンポ良くテストを進めることができます。
その他、データセットの使い方はまだまだ色々考えられるかもしれません。
