継続インテグレーションとデータベースのバージョン管理
翻訳記事も出た事だし，Allen流データベース・バージョニング方法についてちょっと触れとく。
＃Allenさんのブログへのリンクはこちらにまとめといた。
＃→2008-02-20 - marsのメモ
Allenさんが言ってるDBバージョニング方法とは，
- ベースラインとするSQLスクリプト（DDL文）を用意する。
- initial-install.sqlって名前にしとく。
- 変更があるたび，その差分を定義したスクリプトを用意する。
- どのスクリプトまで適用済みなのか分かるようにSchemaChangeLogテーブルを用意して，そこにログを残す。
- ついでに，スクリプトの適用と状態確認ができるようなツールを作っておけ。
てなのが主な論調（たぶん）。なんかRailsのmigrationみたいだね。
んで，どっかに「差分ばっかじゃ全体像を把握できないから，常に全体を定義したスクリプトを用意して，差分はツールにまかせたらどうよ？」みたいなコメントがついたんだけど，確かに一理あるなと思ったよ。
＃「ツールが重くて使いもんにならん」って反論あったけど。
ぱっと思いつく限りだと，ここらへんの課題をクリアしとかんと実行には移れんだろう。
- どこをベースラインとするか。
- 保守フェースも視野に入れると，ファーストリリースがベースラインだよね。
- むろん，開発中もどっかでベースライン作って運用しててもいいだろうけど。
- 差分作る単位をどうするか。
- 闇雲に変更スクリプト書いてたら，それだけで嫌気がさしそうだわな。ありがちなところで，ブランチ単位が妥当かのう。
- どうやって変更スクリプト作る（作らせる）？
- 優秀なDBAが居なくなっても維持できるルールやツールがないと困る。
- 最新のER図とかどっから見りゃいいんダロ？
- やっぱ最新のDBマウントしてリバースですか？
- 差分とは別に，保険として全体のスナップショットも残しとくんだろうなぁ...
課題もいろいろだけれど，この程度のことで済むくらいDBのバージョニングも現実味を帯びてきてるんだなぁと思うべきか。
興味のあるテーマではあるので，機会があったら挑戦してみよう。
＃LiquiBaseとかも使ってみたいし。:-)
