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タスクをまとめて実行するタスクがあります。
