3. Chanko、Ridgepoleを試してみる

　前回の記事でRails周りの環境が出来たので、いよいよChankoとRidgepoleを試してみる。だが、その前に画面を作らなければ行けないの適当にでっち上げる。erbとslimは試していたがhamlは初めて書く事になった。そしてやっぱりhtmlを作成するのが一番時間がかかった・・・。Emmetとかでサクサクっと作れる人がいるのであればすごく羨ましい能力だと思う。

　まずはChankoから。詳しくは本家のドキュメントを見てもらった方がいいが、本番環境でプロトタイピングしちゃおうというフレームワークだ。「Unit」という単位でモジュールを増やしていき、管理を行う。既存のプロダクトソースとは基本別ファイルに作成することになる。そのUnitが有効になる条件等もそのUnitに記載する。プロトタイピング出来る部分は細かく指定することが出来、コントローラのアクション単位や、renderするテンプレートやビューで使えるヘルパーメソッド、モデルに機能を追加することも出来る。そして既存にアクションがまだない場合でも「unit_action」を使って、プロトタイプを追加することも出来る。

　やりたい事としてプロトタイピングなのだが、やはり本番想定でデータがあった方がいいという理論でやっている都合上、当然本番環境で動かすことになる。もちろんUnitが有効になる条件をIPアドレスやユーザ単位等で制限は入れることにはなる。その為Unitが有効でないユーザ用のソースを共存させる必要がある。かつ、念の為プロトタイプでエラーが発生した場合もフェイルオーバーして既存のソースが動くようになっている。デフォルトではこの機能はproduction環境だけなので、開発中は通常通りエラーが出る。

　そしてルール上はプロトタイプにはテストを書かないで良いようだ。これはプロトタイプというのもあるし、スピード感を出す為とのこと。こういった考えは本当に関心する。 　せっかくなのでproduction環境でraiseして本当にフェイルオーバーするか確認したところ、きっちりとフェイルオーバーしていた。（当たり前）

RAILS_ENV=production bundle exec rails s -b 0.0.0.0

　そして次はRidgepoleを触ってみる。これもChanko同様にプレゼン資料等で情報だけは知っていた。migrateを差分で記載していくのではなく」あるべき姿」を管理することでRidgepole側が差分を検知し必要なmigrationを行ってくれる。例で乗っているのはarticlesテーブルがあり、そこへ「author」カラムを追加した場合はSchemafileに以下の様に1行追加してapplyするだけでいい。

# before
create_table "articles", force: :cascade do |t|
  t.string   "title"
  t.text     "text"
  t.datetime "created_at"
  t.datetime "updated_at"
end

# after
create_table "articles", force: :cascade do |t|
  t.string   "title"
  t.text     "text"
  t.text     "author"
  t.datetime "created_at"
  t.datetime "updated_at"
end

bundle exec ridgepole -c config/database.yml --apply -f db/Schemafile

　仕組み上バージョン番号等は無いので、どこまでmigrateされているのかは確認が面倒そうだ。しかしmigrateが増えまくって行くことや、migration番号の衝突などがなくなるのは良いことだと思う。正しい姿をきちんと管理していれば、適用すればそうなるというの安心感もある。本家のドキュメントには色々なパターンの書き方が乗っており、基本的には機能的問題はなさそう。イレギュラーケースの場合はちょっとどうするのか想像できないパターンもあるが、その場合はその時に対処するのだろう。開発者ブログでも記載されているように、全てに使っているわけではない無いらしい。かつ、「開発者が開発DBに自由にALTER」というのはなかなか斬新な発言だとは感じる。この辺はCI周りとテスト周りがしっかりしているからこその開発手法であり、開発スピードを落とさない結果に繋がっているのだろう。

　どちらも素晴らしいフレームワークであり、使えそうなら是非使ってみることをお勧めしたい。時間を作って勉強の為にどちらのソースを読んでみたいと思う。