システム運用が始まってからのDB変更

今回リリースの DBFlute-0.9.7.6 は、様々な場面での
DBFlute利用のサポートが主な対応課題です。
それだけ、色々なパターンのプロジェクトで利用されるように
なったということで、本当に感謝です。

既に運用されているシステムに DBFlute が採用される例を
よく聞きます。それだけを聞くとかなり無謀に思えますが、
(通常、運用中にフレームワークを変えることはありません)
メンテナンスをされている人たちは必死です。

DBFluteは「DB変更に強い」をテーマとしていますが、
着目されやすいのは、やはり今の時代の象徴、開発時のDB変更。
開発前からDB変更が発生することがもうわかっているような場合も。
ただ、DBFluteの真骨頂は、運用が始まってからとも言えます。
来週にも本番に反映されるかもしれない小さな開発のバトンレース、
まだ動くのが先の話の初期開発時とは、コード一行に対する
プレッシャーが大きく異なり、徹底して安全にいきたいものです。

そして、実は運用時も、とてもDB変更が多いもの。
プロジェクトによっては、開発時はあまり発生しないものの、
運用してからじゃんじゃんDB変更が入るようになることも。
そういうことから、開発時は DBFlute なんて眼中になかったのに、
運用に入ってたまらず DBFlute を検討するようになり...
いきなり置き換えは無理なので、まとまった単位のメンテが入った
ときに、新しい部分だけDBFluteで実装、徐々に置き換えていく。
このパターン、少なくとも jflute は複数の現場でみかけています。

ということで、融通の利かない環境、での利用が想定されることが
多々あります。幸いにして、DBFluteは自動生成ドリブン。
うまく化けながら現場にフィットするように調整していけたらと。
(で、でも、もちろん限界もありますよ)