はじめに

前回から少し間が空いてしまいました。。最近、flywayによるマイグレーションを試してみたところなかなかいい感じだったので、ちょっと紹介しようと思います。データベースのマイグレーションツールをまだ使ったことがない人に、その便利さが伝われば良いなと思います。

最初は公式の First Steps: SBT をなぞりつつ、それよりは少しだけ踏み込みながら実際の使用例を考えてみましょう。

(アイコンやサンプルコード等は公式ページのものをいくつか使用させていただきました)

Flywayとは

Flywayはデータベースのマイグレーション管理ツールです。スキーマにバージョンをつけて、今どのバージョンになっているかを確認したり、新しいバージョンへマイグレーションを行ったり、マイグレーションがいつ行われたのかを記憶しておいたりすることができます。

Flywayはコマンドラインツールとしても動作できますが、各種ブラグインも用意されています。今回はその中から、ScalaではおなじみであろうSBTのプラグインである flyway-sbt  を使って、実際にマイグレーションを試してみようと思います。

用意するもの

まずはSBTプラグインを追加します。 project/plugins.sbt に以下を追記してください。(ファイルがなければ作りましょう)

次に、 build.sbt  で必要な設定を行います。
必須項目は接続するデータベースのJDBC URLなのですが、その他にSQLのユーザーやパスワードも必要になるでしょう。今回はH2を使ってまずは動かしてみることを優先します。

設定で変えることもできますが、何もしなければマイグレーションファイルはプロジェクト内の src/main/resources/db/migration  から探されます。そこで、ここに最初のバージョンとなるファイルを置きましょう。ファイル名は公式に習い、 V1__Create_person_table.sql  とでもしておいてください。

初回の動きを見てみる

早速ですが、この状態でまずは実行してみます。マイグレーションを行うには flywayMigrate  を実行します。

公式と同じように、うまくいけば次のようなログが出るかと思います。

まあこれだけだとピンとこないと思うので、次のコマンドも実行してみましょう。これは、flywayが今どんな状況になっているかを知ることができます。

次のようなログが出たでしょうか?

この表示から次のようなことがわかります。

  • バージョン1まで成功していること
  • バージョン1の説明とその実行日時
  • どうやらバージョン2以上はなさそうだということ

最後はどうしてなのか、というのを知るためにもバージョン2を準備してみましょう。

次のバージョンを準備する

これも公式に合わせ、新しく V2__Add_people.sql を作りましょう。

公式の例だとinsertを実行してるのですが、sqlならいいのでもちろんAlter Tableとかでも全然大丈夫です。というか実際はAlterやCreate Tableが大半な気がします。

これを作成したら、実際に実行する前にもう一度 flywayInfo を実行してみましょう。すると今度は違ったログが出てきます。

flywayが新しく作ったファイルをバージョン2のファイルだと認識したようです。また、実行日時は空になっていて、 Pending  と表示されています。これは、まだこのマイグレーションを実行されていないという意味です。

マイグレーションを実行する

では、実行してみましょう。

うまくいけばこんなログが出るかと思います。

それでは flywayInfo を見てみましょう。 sbt flywayInfo  を実行すれば、今度はこんな表示になるでしょう。

バージョン2に実行日時が入りました!また、 State も Success に変わったことが確認できたと思います。

マイグレーションファイルの細かい話

マイグレーションファイルは V から始まり __  (アンダースコア二つ)までの間がバージョンになります。そして __  のあとに続く文字列がDescriptionとして扱われます。

バージョンは今回整数でしたが、本来は .  や _  でいくらでも区切ることができるそうです。細かい修正だから今回は2.1にしよう・・・みたいなことも自由に設定ができます。

どういった使い方ができるか

sbt flywayMigrate  を実行すれば、マイグレーションが行われるか必要なければ何も起こりません。これを利用してCI(継続的インテグレーション)で毎回実行するようにしておけば、DB管理はデータベースがどうなってるかを意識することなく、マイグレーションファイルとそこで定義されたスキーマに基づくアプリケーションの実行だけを考えればよくなります。

また、リリーススクリプトでも実行するようにしておけば、リリース時にうっかりスキーマ変更を忘れるようなこともなくなるでしょう。

一つ注意が必要なのは、flywayではロールバックができないということです。これは本番でやろうとするとものすごい苦労することになるでしょうから、ロールバックが必要になるような状況にはなるべく陥らないように注意する必要があるでしょう。(変更後のスキーマでも旧バージョンが動くようにしておく、など)

最後に

ソースコードはバージョン管理しないと不安になるのに、今までデータベーススキーマの管理について考えていなかったことが不思議な気分になりますね。ぜひ、これを機会にデータベースのマイグレーション管理を取り入れて、より安全にデータベースと付き合っていきましょう。