RailsでのSI開発にRidgepoleは相性がいいのではないだろうか?
仕事でRailsでのSI開発を行っているのですが、毎回悩みの種の1つにDBのMigrationがあります。
SI開発の性質上、どうしても下記のドキュメントが必要であることが多いです。
- テーブル定義書
- ER図
仕事では、これらを作成するツールとして下記のA5:SQL Mk-2を利用しています。
A5:SQL Mk-2 - フリーの汎用SQL開発ツール/ER図ツール
このツールを使うことで、ER図を書くだけでテーブル定義書も出力できるのでとても便利です。
(テーブル定義書は必要に応じて加工することもありますが)
そして、このツールのさらに便利なところが、ER図からDDLを生成できるところです。
案件では開発の立ち上がりを早くするために、設計に利用したER図からDDL生成機能(ER図 > DDLを生成する)を利用してテーブル作成を行っているのですが、 開発初期はテーブル定義が変わることがよくあるので、この方法は重宝しています。
しかし、この方法だとRailsのMigration管理から外れているので、ある程度設計が落ち着いた段階でMigrationファイルを作成する作業が発生する。
(rake db:schema:dumpでschema.rbを生成してもいいですが、既存ではない新規のプロジェクトなのにそれをするのは気持ち悪いし、その後のカラム追加などをMigrationでやっていくのも・・・)
数テーブルなら大した労力ではないが、10を超えたあたりから面倒だしtypo等も発生する可能性がある。
そんな状況がどうにかならないものかと悶々としていたが、最近趣味のアプリで前々から使ってみようと思っていたridgepoleを使ってみて、そのあたりの問題が解決できそうだったのでまとめてみた。
(仕事ではまだ試せてないです)
Ridgepoleとは
簡単に言うと、スキーマ管理ツールです。
Railsのマイグレーションと書き方が同じなので、難なく使えると思います。
詳しくはクックパッド様のブログやGithubをご覧ください。
Ridgepoleを利用したMigrationの流れ
- A5:SQL Mk-2でER図を作成
- A5:SQL Mk-2のDDL生成機能でDDLを生成
- 生成されたDDLを実行
- ridgepoleでSchemafileをエクスポート
- ridgepole --applyでスキーマ作成(各開発者の環境)
その後は、SchemafileをGitなどで管理していく。
(コンフリクトが多発するのではと思われるが、自社の開発においてはスキーマを変更する人は限られるので問題ないと思っている。)
考察
この流れなら今までのツールを利用しつつ、途中でMigrationファイルをつくる手間も省ける!
(Migrationファイルがどんどん増えていくこともない!!)
capistranoなどを利用してデプロイを自動化しているのであれば、下記のようにしてrake db:migrateをridgepole用にしてもいいと思う。
(Deveseなどの導入でrake db:migrationが必要になることもあるので、alias_methodで別名タスクにしたらいいのではないかと思っている。)
追記(2016/07/16)
実際に試してみると、rakeファイル内でalias_methodが使えなかった。。。
どうしようかと調べていると古い記事だけど方法があったので、その方法を使ってる。
※rakeタスクをalias_method的なことする方法を知ってる方いたら教えてください!
参考までに、こんなrakeファイルを作ってる。
gistc670a11fdebb35c6bac3bc2307576854
Deviseなどでmigrationがつくられる場合は、db:migrate:original → db:ridgepole:exportをする。
最後に
他にいい方法や、Railsでの開発でウチはこうしてる!みたいのがあれば教えてください。