DBのバージョン管理で苦労しないために

どうも、小野です。

今回は、開発で意外と問題になってくるDBのバージョン管理についてのお話です。

みなさんは、どのように管理していますか？ DBは開発工程前に予め設計するのですが、やはり変更はつきものです。 しかもDBはアプリケーションの核になっているので、構成が変わるとエラーが発生したり、随時更新していかないと環境によって構成が異なったりします。

私も周知漏れなどで、自分のところでは動くけど、他の環境では動かないなどは日常茶飯事でした。 ちゃんと管理しろって話ですが、エンジニアの人数も少なかったので、管理コストに比べたら、トライアルアンドエラーの方が良かったりします（汗 ただし、エラーログに「〜の列が見つかりません。」のような、エラーのトレースができることが前提ですね。

現状の管理方法における問題点を挙げ、改善方法についてお話します。

今はこうやって管理している

DB設計時に、まずER図を作成しています。ER図を作成するときにA5M2というツールを使っています。

a5m2.mmatsubara.com

このツールはWindowsのみ対応しています。Mac使いの人は利用できません。。

BootCampでWindowsをインストールすることはできますが、A5M2のためにやりたくはないですよね。 「EasyWine」というツールを使えば、Mac上でWindowsアプリ（exe）を実行できるようになります。

forest.watch.impress.co.jp

他のER図作成ツールでWindows、Mac共に対応しているのが、ERMasterというツールです。 これはEclipse上で動くので、Eclipseがインストールされている前提です。

これらのツールの最大のメリットは、ER図からExcelベーステーブル定義書、DDLが出力できる点です。

受託などで、設計書の納品が必要な時はツールから出力したものをお渡ししています。

ツールで出力したデータベースにDDLを適用します。

これで、データベースの準備ができました。

テーブルが追加になったら

1. A5M2を使って、ER図を変更します。
2. 追加対象のテーブルのDDLを出力し、そのままデータベースに対して実行します。
3. 実行したDDLはExcelなどで履歴管理します。

テーブル定義が変更になったら

1. A5M2を使って、ER図を変更します。
2. GUIツールなどで直接変更します。
3. 実行したDDLはExcelなどで履歴管理します。

追加と違って、既存テーブルに対して、変更を行います。 ツールから出力できるのはCREATE文のみなので、ALTER文の作成が必要になってきます。

ここでGUIツールが出てきましたが、今はDBeaverというツールを使っています。

dbeaver.io

このツールの良いところは、様々な種類のDBに対応している点です。 Eclipseベースなので、Eclipseが動く環境であれば、利用可能です。

DBeaverはGUIから直接、テーブル定義を変更した場合、変更分のDDLが作成されます。

問題点

変更の履歴管理はできているように見えますが、ここで問題なのが、他の環境でも適用が必要だということです。 変更した人が、チャットやメールなどで他のエンジニアに周知する必要が出てきます。 しかも、周知されたエンジニアは後回しにする可能性があり、結局、エラーになったときにExcelを確認し、DBを更新することになります。

多くの場合、アプリのバージョンとDBのバージョンはリンクしており、DBのみ最新にしてもエラーになることがあります。 なので、DBの履歴管理上でアプリのどのバージョンに対応などに記載が必要な場合もあります。

ちゃんとやろうとすると、管理コストがかかってしまうのです。

解決方法

前述の問題を解決するのが、マイグレーションツールです。 Ruby on Railsにはフレームワーク上にそういった機能が同梱されているため、DBのマイグレーションはできていると思います。

しかしながら、私が主要で使っているJava（javaEE）に関してはそのような機能はありません。 流行りのSpringBootにも標準ではついておらず、マイグレーションが実現できません。

そこで、Flywayというツールを導入することによって、マイグレーションを実現することができます。

flywaydb.org

使い方は以下の記事を参考にしてください。 qiita.com

これを利用すると、以下のメリットがあります。

• Excelによる履歴管理が不要
• 周知が不要
• プロジェクトビルド時にDB更新

今後はこうやって管理する

テーブルが追加になったら

1. A5M2を使って、ER図を変更します。
2. 追加対象のテーブルのDDLを出力し、SQLファイルとしてFlyway適用フォルダに保存する。

テーブル定義が変更になったら

1. A5M2を使って、ER図を変更します。
2. ALTER文を作成し、SQLファイルとしてFlyway適用フォルダに保存する。

DBへ適用

開発者はいつも通りにビルド、実行を行うだけで、DBはアプリケーションと同期されます。 なぜ、アプリケーションと同期されるのかというと、SQLファイルもソースと同様にバージョン管理ができるからです。 これで、アプリとDBのバージョンに差異がなくなりますよね。

おわりに

テーブル定義変更文のDDLを作成する手間はありますが、Flyway導入前と比べたら、管理コストが減るので、導入する価値はあると思います。 もし、DBの管理に苦労している方は、ぜひ、導入してみてください。
そして、DB管理から解放されましょう。