DBマイグレーションについて決める

HomMarkHunt commented 8 years ago

前提

DBを使用する際に下記理由からマイグレーションツールを使用する。

各環境(今の所想定は各々のローカルと本番環境)で容易にテーブル作成などを容易に行うために使用する。
araingeeの要件としてテーブル構成が頻繁に変わることが想定されるので、DBのバージョン管理を行えるマイグレーションツールを使用する。
使用するツール
Flyway

選定理由

選考対象に Liquibase
Liquibase のほうが高機能で複数のDBのサポートなどに強い(確信)
肝心の実行用のSQLが
- Flyway : Plain SQL(標準DDL)
- Liquibase : Liquibase XML, Liquibase annotated SQL(Plain SQLのサポート無し)

という違い。

Plain SQLを書きたい(Liquibase用のDB定義を覚えられる気がし無いみんなパニックになる)
Flywayも怪しいのでできるだけ低機能でシンプルに使えるFlywayのほうがいい
今回の使用用途として、DDLを流す、DBのバージョン管理くらいしか想定されてい無いので。Liquibaseの高機能はオーバースペック
Java migrations (JDBC API を使ったJavaクラスのマイグレーション) がFlywayのみ

以上の理由からDBのマイグレーションツールはFlywayを使用する。

Flywayの開発環境

Flaywayが管理するパッケージ群をじゃばますOrganization配下に専用のリポジトリを作成して管理する。
SQLの変更は当該リポジトリにてCommit
Localでの使用方法
各PCにFlyway Command-line Toolをインストール。
Github上からFlyway用リポジトリをclone(二回目以降は最新をpull)し、当該ディレクトリにて Flyway Commandを実行。
テーブルなど、最新のものが配備される。
issue終了条件

@dodoichi @disc99 2名によるLGTMを獲得。

dodoichi commented 8 years ago

LGTM

disc99 commented 8 years ago

2点確認

Flyway Command-line Toolは本番環境でも使用する？となるとサーバにもToolをインストールする前提？gradlewやmvnwみたいな実行環境依存の無い仕組みで構築する前提じゃなくても大丈夫？
別リポジトリで管理する場合、開発中のアプリリポジトリとFlywayリポジトリの整合性はどうやって維持する？場合によっては、ブランチ単位でテーブル構成が違ったりする状態は発生するはず。

HomMarkHunt commented 8 years ago

@disc99

Flyway Command-line Toolは本番環境でも使用する？となるとサーバにもToolをインストールする前提？gradlewやmvnwみたいな実行環境依存の無い仕組みで構築する前提じゃなくても大丈夫？

当初はサーバにもToolをインストールし、sshで手動でflyway migtrateとか叩く想定でしたが、手動での実行は事故りそうなのと某靴ECサイトの筋肉の人にアドバイスをもらい。

migrate用のシェルを作る参考
ビルドツールから実行するようにする

のどちらかを考えています。

ビルドツールが決まっていないので今一歩決めかねている状況です。

別リポジトリで管理する場合、開発中のアプリリポジトリとFlywayリポジトリの整合性はどうやって維持する？場合によっては、ブランチ単位でテーブル構成が違ったりする状態は発生するはず。

たとえばaraigneeのfeature/hogeで開発中にDBの変更があった場合はDB用リポジトリもfeature/hogeを作成して整合性を維持する想定です。

で、あればaraignee内でflawayも管理すれば... とも最初に思ったのですが。araigneeがデータ格納したDBを使う側アプリ(名前未定)の作成中にDB構成を変えるケースがほぼ確実にあるかなと考えています。

その時にDBの変更するためにaraignee自体を変更するのではなくDBだけは別で切り出したほうがわかりやすいかなと思ったのでこの構成を考えました。

回答が的を得ていなかったらすみません。

disc99 commented 8 years ago

たとえばaraigneeのfeature/hogeで開発中にDBの変更があった場合はDB用リポジトリもfeature/hogeを作成して整合性を維持する想定です。

運用方法が決まっているのであれば、別リポジトリでも大丈夫かな！分離して管理するのが手間であれば、後で統合してもいいだろうし。

それと、Command-line Toolは使ったこと無いからよく分かってないけど、実行環境にインストール前提で開発を進めていくと後々環境の管理に苦しみそうだから、ビルドツールだけで完結できてたほうが、環境移行やローカルの環境構築も楽になると思う。

chappieがマイグレーションしてくれるってのも面白そうではあるけどｗ

HomMarkHunt commented 8 years ago

ビルドツールだけで完結できてたほうが、環境移行やローカルの環境構築も楽になると思う。

ありがとうございます！実行方法を調べてみたのですが、

command line tool(ターミナルからflywayコマンドで実行)
javaから実行(コード内からflywayを実行)
Gradleのpluginとして実行

という方法があるみたいです。ローカルは1. 本番は3.の実行方法がいいかなと思いました。

一度手元で諸々試してみます！

disc99 commented 8 years ago

ローカルを1にしたい理由はある？それだと環境によってコマンドを使い分けないといけないのと、command line toolのバージョンコントロールが出来ないから、ローカルも本番も全部Gradleで実行するようにしてしまったほうが楽な気もするけど！

HomMarkHunt commented 8 years ago

ローカルを1にしたい理由はある？

あー。これは以前現場でflyway使ってた時にローカルはコマンド叩いてたから。ってだけですね！確かに両方Gradleから実行のほうが良さそうです！

disc99 commented 8 years ago

HomMarkHunt commented 8 years ago

まとめ書いてて出てきた確認したいことがでてきました。

migrateするgradleタスクはどこに記述するか

araignee内のビルドスクリプト
DB管理リポジトリのビルドスクリプト

のどちらにgradleタスクを書くべきか？当初ふわっと考えていたのが 「DB管理リポジトリをgradleで作成して build.gradle 内にmigrate用の諸々を記述」 です。その場合、

サーバーにDB管理用のプロジェクトを配置(デプロイ？)
migrate時はサーバーにアクセスしてmigrate用のタスクを実行

もしくは、

araignee内のビルドスクリプトにmigrate用のあれこれを記述してデプロイ後にタスク実行できるようにする

のどちらかの方法で実行できるようにする必要があると思いました。

この認識であっていますでしょうか？

dodoichi commented 8 years ago

こういうことを悩むくらいなら、レポジトリを分けない方が良いだろうね。

HomMarkHunt commented 8 years ago

むむむ... 確かによくわかってないですぞ...

Gradleから実行されるFlywayがどこのSQLをいつ実行するのかがよくわかっていないなと思いました。まとめ書いてて、仰る通り「araigneeに書いたほうがまだわかるのでは...」と思っていました。

今回はaraigneeの build.gradle に記述して、SQLもaraignee内に含める。に返させていただこうと思います。

お二人せっかく見ていただいたのに申し訳ございません。一旦まとめ直します。

また、今度お時間あるときにちょっと質問させていただけると嬉しいです。

dodoichi commented 8 years ago

[ LGTM ]

HomMarkHunt commented 8 years ago

このチケットで決めるべきこと。(flywayを使う)は決まり、終了条件であるLGTM2つも獲得済みなので、本チケットはクローズし。 Flywayをどのように利用していくかは #39 にて決めます。よってクローーーズ！！

javamas / araignee