DB変更が発生したら
DB変更が発生したら何をする？
DB変更が発生したときのDBFluteタスク実行の流れは以下のようになります。 アーキテクト(つまり誰か一人の人)が中心となって、ディベロッパーと連携をとりながら以下の作業を行っていきます。
1. ReplaceschemaでDBスキーマ再作成 (+ AlterCheck)
ERDツールでDDL文を再生成した後、それを使ってDBスキーマ(ローカルDB)の再作成を行います。 マスタデータやテストデータにも影響がある場合は、エクセルデータも修正します。
運用後のDB変更であれば、AlterCheck も活用すると良いでしょう。(タイミングは任意です)
2. JDBCタスクでメタデータを更新
DBスキーマが最新になったので、DBFluteが保持しているメタデータを最新のものに更新します。
3. Docタスクで最新版のドキュメントを自動生成
schemaHTML や HistoryHTML などを再自動生成します。
4. Generateタスクで最新版のクラスを自動生成
Entity や ConditionBean などを再自動生成し、DB変更の影響範囲、つまり、コンパイルエラーになる箇所を修正します。 業務的な影響範囲は、アーキテクト自身がバージョン管理システムにコミットする前に直すか、 コミットしてからディベロッパーに直してもらうかはポリシー次第、もしくは、状況次第です。
5. OutsidesqlTestで外だしsQLの影響範囲の検知と修正
sQLの文法レベルで露骨に影響するものに関しては、ここでタスクエラーとなるので、そのエラー内容をみて影響範囲を修正します。 あまりに影響範囲が多い場合、アーキテクト自身がバージョン管理システムにコミットする前に全てを直すか、 エラーが発生する状態のままコミットしてディベロッパーに直してもらうかはポリシー次第、もしくは、状況次第です。
OutsidesqlTestタスクは、sql2Entityタスクでの実行対象外のsQLも対象となるので、 (次の)sql2Entityタスクだけをやっていればいいというわけではありません。
6. sql2Entityで外だしsQL構成の影響範囲の検知と修正
sQLの結果構成(select句)や検索条件に影響するものに関しては、CustomizeEntity や Parameterbean の再自動生成をして、DB変更の影響範囲、つまり、コンパイルエラーになる箇所を修正します。 業務的な影響範囲は、アーキテクト自身がバージョン管理システムにコミットする前に直すか、 コミットしてからディベロッパーに直してもらうかはポリシー次第、もしくは、状況次第です。
ReplaceschemaのDDL、エクセルデータ、Docタスクの schemaHTML や HistoryHTML、Generateで自動生成されたクラス、OutsidesqlTestで直した外だしsQL、sql2Entityで 自動生成されたクラスなど、もろもろをバージョン管理システムへコミットします。
7. 自動単体テスト(JUnit)を全て実行
JUnit(など)で作成した自動単体テストを全て実行して、グリーンになることを確認します。 業務的な影響範囲でアーキテクト自身が直し切れない場合は、ディベロッパーに直してもらうことも考慮します。
8. 割り切ったもの以外の修正が終わったらコミット
アーキテクトだけでは直し切れない修正がある場合は、コミット後にディベロッパーにその旨をしっかり通知して直してもらいます。 ディベロッパーから修正報告があって、JUnitの単体テストなどが全て通るようになったらDB変更完了です。
9. ディベロッパーはバージョン管理システムから最新を
ディベロッパーはバージョン管理システムから最新のリソース(DDLやエクセルデータやソースファイルなど)を更新します。 ローカルDBだけは最新にはなっていないので(DB自体はバージョン管理システムで管理しないので)、Replaceschemaを叩きます。
割り切られた修正があれば、それぞれ自分が担当する修正を行いアーキテクトに報告をします。
これにてDB変更完了です。
一括で実行するタスク
DB変更が発生したらやるべきDBFluteタスクをまとめて実行するタスクがあります。
