DBは開発、検証、本番で異なるのでflywayもそれに対応して運用する必要がある。
利用するconfファイルはコマンドラインオプションで指定できるので、DBごとにconfを用意して実行することが可能。
また、オプションを指定したコマンドを実行するシェルを利用してもいい。
なので、（当然だけど）複数環境に対応できないわけではない。
そして個人的に問題というか、面倒だったのが
「flywayは現状のsqlファイル適用バージョンより低いバージョンのsqlファイルを実行しない」
という点。
開発環境では複数の実装が並行して走っていて、リリース順もバラバラな可能性があるので、
sqlファイルのバージョン順にリリースするとは限らない。
大きい値のバージョンを先行リリースしてしまうと、それより小さいバージョンのsqlファイルは実行されなくなるので、
開発では小さいバージョンだったファイルが検証だと大きいバージョンで管理されている可能性がある。
つまり、開発、検証、本番でバージョン番号の整合性が取れなくなる。
これがイヤだった。
開発ではflywayを利用しない選択肢もありかもしれない。
開発ではSQLを直接実行するだけで、検証、本番反映時にsqlファイルに開発で実行したsqlを書く。
検証と本番でバージョンの整合性が取れればいいという考え。
ただ、検証、本番でリリース順がバラバラだと無意味だから微妙・・・。
もはやgitのリポジトリも開発、検証、本番で別にして、
flywayのバージョン番号自体は実行順と割り切って、
ファイル名のdescription部分でバージョン管理した方がいいかもしれない。
以下は v1 というバージョンを付けた例。
例：V1__v1_create_table.sql
こうなってくると、そもそもバージョン管理する必要もないと思う。
バージョンは同じSQLを複数回実行しなくするものであって、SQLの実行順が開発、検証、本番で異なるとかどーでもいいと割り切る。
実行順が前後して問題になるsqlは1つのファイルにまとめればいい。
ということで最終的に以下の運用方法にしようと思う。
sql
├── dev
│ ├── db1
│ │ ├── V1__create_table1.sql
│ │ ├── V2__create_table2.sql
│ │ ├── V3__create_table3.sql
│ │ └── dev_db1_migrate.sh
│ └── db2
│ └── dev_db2_migrate.sh
├── pro
│ ├── db1
│ │ ├── V1__create_table1.sql
│ │ ├── V2__create_table3.sql
│ │ ├── V3__create_table2.sql
│ │ └── pro_db1_migrate.sh
│ └── db2
│ └── pro_db2_migrate.sh
└── stg
├── db1
│ ├── V1__create_table1.sql
│ ├── V2__create_table3.sql
│ ├── V3__create_table2.sql
│ └── stg_db1_migrate.sh
└── db2
└── stg_db2_migrate.sh
開発、検証、本番で分けて、さらにDBごとに分けておく。
dev, pro, stg が個別のgitリポジトリで管理されているイメージ。
sqlファイルは開発と検証、本番でバージョンが違う（実行順が違う）けど気にしない。
それぞれ独立したものとして考える。
マイグレーションの実行自体は毎回オプションの指定とか面倒なので、シェルにする。
dev,pro,stgのDBディレクトリ毎にシェルを設置して、マイグレーション実行時はこのシェルを叩く。
シェルは以下のようなflywayコマンドを直書きするだけ。
DB接続情報は直接オプションで全指定しても、confにまとめてコマンドでconfのみ指定してもいいと思う。
以下はconf指定の例。
/root/flyway/flyway -configFile=conf/dev_db1.properties migrate
今後はこーゆー感じで運用しようと思う。
