db:rollbackやdb:migrate VERSION後のPendingMigrationErrorの対処法について

Question

Ruby on Rails5でWebアプリ開発の勉強をはじめた初心者です。
Railsでは複数個のmigrationファイルについて、rollbackやVERSION指定によって容易にバージョン管理ができ、アプリケーションについて任意のバージョンに切り替えて公開することができるのだと思っていたのですが、いざrollbackなどでバージョンを下げてからブラウザでアプリケーションを開くとPendingMigrationErrorになります。

もちろんrollbackなどで然るべきバージョンまで下げた後、migrationファイルをdbのディレクトリから移動すればバージョンを下げることができますが、わざわざそのようなことを自分でしなければならないのでしょうか？

それとも何か私が勘違いをしていて、dbディレクトリ配下にmigrationファイルを置いたまま、任意のバージョンでアプリケーションを公開する手段があるのでしょうか。

みなさんがどうしておられるかや、実際の開発現場でどうのような方法が取られているかをおしえて頂けると嬉しいです。よろしくお願いします。

Answer 1

マイグレーションは全て実行しなければいけません。
そうしないと、PendingMigrationErrorが発生します。
そういう仕様です。

Railsでは複数個のmigrationファイルについて、rollbackやVERSION指定によって容易にバージョン管理ができ、アプリケーションについて任意のバージョンに切り替えて公開することができるのだと思っていたのですが、

いや、そんなわけがないでしょう。
まず先にRailsの仕様があり、その仕様に合わせて開発するのです。
こっちの勝手な思い込みの通りにRailsが動いてくれるわけではありません。

ソースコードはgitやsubversionでバージョン管理を行い、すべてがきちんと動作する段階になったらリリース用のブランチやタグを作成し、production環境にデプロイします。
開発は開発用ブランチで行います。

Comments

[mitsukage]

迅速なご回答ありがとうございます。
たしかに、ソースコードの有無についてはgitなどで管理すればよいのですね。
腑に落ちました。どうもありがとうございます。

[mitsukage]

ちなみになんですが、全てのファイルをgitで管理する場合には、もはやrollbackのようなdb管理コマンドはほとんど必要ないのでしょうか。
任意のバージョンをローカルに持ってきて、一からdb:migrateするだけで事足りるように思うのですが。

それともそうせずに既存のデータベースをrollbackなどを用いてちゃんとバージョンを下げることの利点が存在するのでしょうか？

もしよろしければご教授頂けるとありがたいです。

[mingos]

え、例えば１つ前か2つ前のテーブルについてちょっとカラムを追加したり、修正するだけのために一からDBを作り直すのですか？
データの再登録も件数が多い場合、数分を超えます。
その待ち時間はかなり無駄ですよね。
中規模の開発ではマイグレーションファイルの数は50とか100とかになるケースもあります。

[mitsukage]

なるほど、開発現場ではそのような事情になっているのですね。
色々と教えて頂きどうもありがとうございました。