継続的デリバリー読書会#5に参加 / DBマイグレーションツール

DevOps

@kyon_mm さん主催の読書会も第五回になりました。
今回の対象範囲は

  • 第10章 アプリケーションをデプロイ・リリースする
  • 第11章 基盤と環境を管理する
  • 第12章 データと管理する

でした。どの章も本業と関わりが深く、参加されたみなさんとのディスカッションでもいろいろと考えさせられることが多くありました。
個人的には、過去に参加したプロジェクト(開発者20人くらい)で「刻々と変化するDBスキーマとアプリの整合性をどうやって維持するか」という作業に悩まされた経験から、第12章の内容が非常に示唆に富んでいました。ここは今後も掘り下げていきたいと思っていますが、忘れてしまう前に現時点での自分なりの見解をまとめておきます。

マイグレーション用SQLを直接書くケース

MyBatis Schema Migrationsがよさそう。@kyon_mm さんが実際にプロジェクトで利用しているそうです。
http://code.google.com/p/mybatis/wiki/Migration
SQLを直接書けるので柔軟性が高いのがメリットですが、マイグレーションスクリプトがDB依存になってしまうことや、アプリケーション側(Java系言語想定)との対応関係が見えづらくなってしまうことが課題ではあります。
書籍ではDbDeployというツールを紹介していますが、これよりもMyBatis Schema Migrationsの方が高機能かつ活発にメンテされているようですね。

マイグレーション用SQLを直接書かないケース

DBに依存しない何らかの定義ファイルやドメインオブジェクトをベースにマイグレーションを記述する手法になるかと思います。
ER定義をベースとするタイプでは、Jiemamyが使えそうです。(最近滞っているようですが。。。)
http://jiemamy.org/display/PORTAL/Home
ドメインオブジェクトをベースにするタイプはRailsのmigrationが先駆者だと思うのですが、Java系であればGrailsのモデルオブジェクト(GORM)を利用するというアイデアがあります。実際にどこまで使えるかはこれから検証したいと思いますが、既存のDBスキーマからリバースでモデルを生成し、それをGrailsのmigration pluginで扱うことができればSQLレスのマイグレーションができるかも、という話です。
http://grails-plugins.github.com/grails-db-reverse-engineer/
http://grails-plugins.github.com/grails-database-migration/