DBマイグレーションツール(Schemeマイグレーションツール): Evolutions と Flywayについて調べてみた
はじめに
DB(Scheme)マイグレーションツールを使うにあたって,いろいろ調べたことをまとめて置こうと思う. 基本的には,EvolutionsとFlyway焦点をあててます. この2つのどちらを採用すればよいかを考えるために調査しました. 実績や運用時の失敗などがあれば教えていただけると幸いです.
DBマイグレーションツールとは何をするものなのか
DBマイグレーションとはDBMSの移行をすることで(例えばMySQLからPostgreSQLへ移行するとか), それをサポートするツールのことを指す. この機能は,Railsでいち早く採用されたらしい(RubyにはMigr8というのがある). しかし,調べているとDBMSの移行という意味よりも, TABLEのSchemeマイグレーションのことを指して言っていることもあった.
EvolutionsもFlywayもPlainなSQLファイルを使ったSchemeマイグレーションツール. 簡単に言うと,スキーマのバージョン管理のようなもの. と言いつつも,TABLEにはデータが入っているため,特定のバージョンに戻すのは難しい.
記述方法
記述内容
大きく分けてUpとDownがある. - Up: バージョンを上げるときの動作(Railsでは migrate) - Downs バージョンを戻すときの動作(Railsでは rollback)
ここで,Evolutionsとflywayをみてみると. 基本的にどっちもrollbackはできない(gitみたいに前のバージョンにホイッと戻せない). FlywayはそもそもDownsが存在しない(逆に安全?).
Evolutionsの挙動
挙動があやしいとの噂があるEvolutions.
Downsについて
Downはいつ実行されるかという件を調べていたら次のような記事があった.
簡単に訳すと, Downsはスクリプトが変更された時に使われる. 2.sqlがあって,2.sqlが変更されたとする.するとPlayはDownsを走らせてから新しい2.sqlのUpsを走らせる. 知るかぎりではDownsを手動で実行する方法はなく,それはApplicationとDBの関係を崩す状態になるため,エラーが起きる可能性がある. もし,戻したい変更を書くなら3.sqlのUpsに書くといい.
sqlファイルに変更があった場合の実行順序について
簡単にまとめると, Evolutionsは一番purefixの大きいSQLファイルに変更があった場合,対象のファイルのDownsが走ってから新しいUpsが走る.
FlywayとEvolutions
FlywayとEvolutionsとかいいつつも,Flywayに関することしか書いてない. Evolutionsを選ぶ理由が特にないというのもある...
どうやって選ぶのか?
などの条件を考える感じになりそう.
選択肢
- gitで管理
- Evolutionsを使う
- Flywayを使う
- Liquibaseを使う(XML)
Evolutionsはいろいろ,良い噂を聞かないのでまず却下. LiqibaseもDBMSの鞍替えとかは考えないので却下. gitでも,Flywayのどっちかかなという感じ. Playと連携させるとするとFlywayかなぁ.
Evolutionsを使った人達の声
- いつ動くかよくわからない
- コマンドで任意のタイミングで動かせな
- evolutions の動作について質問です