カテゴリー: BackEnd

さらば「rails migrate」、よろしく「ridgepole」

1 はじめに
2 Ridgepoleとは
3 rails migrateではなく、Ridgepoleを選定した理由
4 rails migrateからRidgepoleへの移行手順
5 capistrano3でのdeploy時にRidgepoleを実行
6 Rspecを利用している場合
7 さいごに

はじめに

こんにちは、本日はDBスキーマを管理すためのツールの一つである「Ridgepole」についてブログ投稿をします。

「rails migrate」ではなく、なぜ「Ridgepole」を使ってみたかなどの背景から、「rails migrate」からの移行手順まで記載しましたので、ぜひ最後までお読みいただければと思います。

Ridgepoleとは

railsのmigrateのようなDBスキーマを管理すためのツールです。クックパッドのエンジニアの方が開発され、GitHub上で公開され、gemとして簡単に組み込むことができます。

https://github.com/winebarrel/ridgepole

特徴としては、下記があります。

カラム追加/削除、インデックス追加/削除などの変更の度にmigrateファイルを作成するのではなく、テーブル定義（Schemafile）を修正するだけとなります。
ridgepoleは、実行時にテーブル定義を記載したファイル（Schemafile）と実際のDB上のテーブル定義（実行の都度、アクセスし取得）とを比較し、差分があればその差分だけが実行されます。
Schemafileの記述方法は、rails migrateと同じDSLで記載ができます。（若干異なる部分もありますが、特段問題にはなりません。）

rails migrateではなく、Ridgepoleを選定した理由

正直言うと、rails migrateで、現在開発中のプロジェクトであれば、全く問題はありません(笑)。また、rails migrateはrailsに標準で組み込まれているため、他の開発者の認知度も高く、railsともにコミュニティでメンテされるため、安心感もあるかもしれません。

では、なぜridgepoleを使うことにしたのか！それは、「使ってみたかった」からです。Webサイトや他社での利用事例は読み聞きしていますが、実際のプロジェクトで利用経験がなかったため、使ってみたいと思い、今のプロジェクトは一からgemやら開発方法やらを自己責任で決定できるので使ってみようと思いました。

とはいえ、それだけでは開発メンバへの説明にならないので、実用的には下記を説明しています。

テーブル定義を「Schemafile」だけで管理し、テーブル定義変更のたびにmigrateファイルを作成しなくて良い。
- 複数人で開発しているとmigrateファイルの内容がバッティングしたり、初期開発時のカラム追加/削除などで、うまく管理しないとあっという間にmigrateファイルが増えていきますが、それを防ぐことができます。（テーブル定義の変化の履歴は、gitで見れば十分です。）
現在の最終的なテーブル定義が「Schemafile」で管理できる。
- rails migrateでもschema.rbに集約されますが、rails4まではcommetが除去されていたり、rails5であってもmigrateファイル内のrubyのコメント(# コメント）は当然除去されてしまいます。テーブル定義が各種コメントと一緒にSchemafileだけで管理できるのは、改めてテーブル定義書などをwikiやらスプレッドシートで管理しなくてよいので助かります。
rails migrateと同じDSLで記述ができる。
- 開発メンバの学習コストをおさせて、移行ができます。

rails migrateからRidgepoleへの移行手順

1. Gemfileにridgepoleを追加

gem 'ridgepole'

2. 既に存在する DB 上のテーブル定義を Schemafile にエクスポート
「Schemafile」ひとつでと上で書いておきながら、今回はテーブル毎にスキーマファイルを分割します。（–splitオプション）

./bin/bundle exec ridgepole -c database.yml -E development --export --split --output db/schemas/Schemafile
Export Schema
  write `db/schemas/user_favorite_contents.schema`
  write `db/schemas/schemas/users.schema`
  write `db/schemas/Schemafile`

3. db/migrateフォルダを削除
もう、rails migrateは使用しないため、潔く削除しましょう。
4. テーブル定義変更後にridgepoleの実行

./bin/bundle exec ridgepole -c config/database.yml -E development --apply -f db/schemas/Schemafile

5. おまけ：RubyMineでsyntax highlightさせる
.schemaファイル及びSchemafileファイルはrails migrate DSLと同じsyntaxですが、RubyMineの初期設定ではsyntax highlightされません。
そこで、設定を変えておくだけで視認性があがるのでやっておきましょう。（Macでの説明です。）

上部メニューの[RubyMine]-[Preferences…]を選択し、設定画面を開きます。
左側のメニューから[Editor]-[File Types]を選択し、Rubyを探しましょう。
Rubyを選択したら、[Registered Patterns]に「*.schema」と「Schemafile」を追加（+）しOKを押せば、以降はsyntax highlightされています。

capistrano3でのdeploy時にRidgepoleを実行

1. Capistrano3でのdeploy環境の基本設定をする
ここは割愛します。
2. Gemfileにcapistrano3-ridgepoleを追加

group :development, :test do
  gem 'capistrano'
  gem 'capistrano-rails'
  gem 'capistrano-rbenv'
  gem 'capistrano-bundler'
  gem 'capistrano3-ridgepole'
  gem 'capistrano3-unicorn'
end

3. deploy.rbもしくは、deploy/production.rbにridgepole関連の設定を追加

set :rails_env, 'production'
set :ridgepole_env, fetch(:rails_env)
set :ridgepole_roles, :db
set :ridgepole_schema_file, File.join(current_path, 'db/schemas', 'Schemafile')
set :ridgepole_config_file, File.join(current_path, 'config', 'database.yml')

4. deploy.rbにridgepoleが実行されるように設定

after 'deploy:publishing', 'ridgepole:ridgepole_apply'
namespace :ridgepole do
  desc 'ridgepole apply'
  task :ridgepole_apply do
    invoke 'ridgepole:apply'
  end
end

5. その他
必要に応じてdb:migrateが実行されないようにするなどを環境に合わせて修正してもよいでしょう。

Rspecを利用している場合

rspec実行時にmigrationのチェックがはしらないようにspec/rails_helper.rbで該当箇所をコメントアウトしておきましょう。

# Checks for pending migration and applies them before tests are run.
# If you are not using ActiveRecord, you can remove this line.
# ActiveRecord::Migration.maintain_test_schema!