Ruby on Railsのマイグレーション運用について徒然なるままに

真夏になったと思ったら花粉症とかアレルギーが激しくなってきた下條です。今の季節はイネ科の花粉が飛んでいるらしいです。

以前、Ruby on RailsでのDBスキーマの管理方法としてRails標準のマイグレーション機能ではなくRidgepoleを利用した運用をご紹介しました。ぼくらのかんがえた さいきょうの DBスキーマうんよう(Rails版)。Ridgepoleを利用する場合のDBスキーマ運用時には、Ridgepoleで管理するスキーマファイルを更新していって、Ridgepoleがそのスキーマファイルと実際のデータベースの差分を埋めるSQLを発行してくれます。

Ridgepoleを使った運用は弊社での一部プロジェクトでうまく回っているのですが、諸事情によりRidgepoleを使わずに、標準のRailsマイグレーションを利用している場合もあります。例えばプロジェクトの納期がタイトで、できる限りRails Wayから外れずにリスクを減らしたいといったような場合です。ただ、標準のRailsマイグレーションは特にプロジェクトの初期段階で面倒な部分があります。今日はそのお話です。

上記に引用した記事で

開発の初期段階にはDBスキーマが頻繁に変わることがあるため、膨大な数のマイグレーションファイルができてしまう。

と書きました。実際にはマイグレーションファイルの数が膨大になるという問題というよりは、マイグレーションファイルを作ることが面倒という方が問題でしょうか。例えば、一気に多数のカラムの名称変更をしたいというような場合にマイグレーションファイルを新規で作るよりは、既存のマイグレーションファイルを修正してカラム名を変えてしまったほうが楽です。

その一方、各開発者の開発環境などのことを考えると、既存マイグレーションファイルを変更されると、再度 rake db:migrate:reset や rake db:resetなどで最初から作り直しになってしまうので勘弁してよということにもなります。開発用データの再作成も必要になります。しかしながら、いずれにせよ大掛かりなDBスキーマ変更では各開発者の開発用データも作り直しになってしまうことがよくあり、それであれば結局既存マイグレーションファイルの修正をしてもいいのではないかという話にもなります。

※もちろん、マイグレーションにはDBスキーマのバージョン管理をするという目的がありますので、既存マイグレーションファイルを修正するというのはある意味邪道なやり方とは思います。ただ、実際のところプロジェクトの初期段階などで大きくDBスキーマが変更されていく際に、毎回マイグレーションファイルを作ってると面倒だよーというのも事実だと思います。

じゃあ結局どうすればいいのか

DBスキーマ変更時に発生するコストとして、以下の2点を考慮に入れてみます。

• DBスキーマ変更自体のコスト
• DBスキーマ変更に伴う、各開発者の開発用DBの作り直し、開発用作成に関するコスト

一般的には、

• 開発初期：DBスキーマの変更が多い。各開発者の開発用データはまだ整っていない。
• 開発後期：DBスキーマの変更は少ない。各開発者の開発用データはできる限り作り直ししたくない。

ということが言えるかと思います。

それを踏まえて、DB変更時のトータルコストを考えると、

• 開発初期においては、既存マイグレーションファイルを修正
• 開発後期においては、既存マイグレーションファイルを修正せずに、新規マイグレーションファイルを追加

というのがトータルコストを減らせるのかもしれません。

そうなると、開発のあるタイミングまでは既存マイグレーションファイルの修正はOKだけれども、それ移行は既存マイグレーションファイルは修正せず、新規マイグレーションファイルを追加で対応するというような運用があり得ると思います。もちろん開発人数・体制やその他の事情もあるかと思いますので一概には言えないと思いますが。

とはいいつつも、これまでの感覚的にはRidgepoleを利用した運用が一番やりやすい印象です。今後はできる限りRidgepole運用に移行していくことになるかもしれません。

Ruby on Railsを活用したWebサービスや業務システム開発をご検討の企業様は、是非MMMにご相談下さいませ！

shimo