DBリファクタリング読書会は、前から気になっていた勉強会で、今回たまたまタイミングがあったので参加して来ました。
今回は3章の「データベース・リファクタリングのプロセス」でした。
まずは、ビールとピザで腹ごしらえをしてから講演、全員が参加してのディスカッションという流れで読書会は進んでいきました。懇親会が本番みたいな勉強会が多いので最初から懇親会というコンセプトは話も弾んで良かったと思います。
読書会中のツイートはこちらでまとめられています。また、全体的な流れはgarage-kidさんがブログにまとめているのでそちらを参照されると良いかと思います。ここでは読書会の本編とも言える座談会の内容について個人的に気になったテーマをピックアップして紹介します。
実際のプロジェクトでDBリファクタリングを実践したことがある人？
15人位中 3人
やはり、DBの修正はできれば避けたいというのが一般的ということなのでしょうか。そんな中、DBリファクタリングを実際のプロジェクトに適用したt-wadaさんの経験談が非常に勉強になりました。railsのプロジェクトでは開発プロセスの一部として当たり前のようにDBリファクタリングをしているそうです。ただし、シングルアプリケーションに限ります。
マルチアプリケーションのデータベースリファクタリングについてもディスカッションがありましたが、シングルアプリケーションの場合と比べて単純ではない、でも出来なくはないという印象でした。
マイグレーションを適用した後にロールバックすることは何処まで実現できるか？
個人的に凄く気になっていたので質問してみました。
- そもそもプロダクション環境でロールバックが必要にならないよう、その前段階で十分に検証を重ねることが前提。
- 逆変換が書ければロールバックは基本的にはできる。逆変換がないマイグレーションがpull requestされてもリジェクトする。
- データを統合するようなマイグレーションの逆変換を書くことは不可能なのでそういう状態にならないように設計段階で注意をする。
というお話を聞けました。 さらにマイグレーションに関して、
- マイグレーションは細かいステップで作ったほうがレビューをしやすい。
- ただし、プロダクション環境に適用する前に見直して重複した更新を省いたり、更新したけど結局戻したみたいなマイグレーションを整理して軽くする。
- マイグレーションの適用時間 = システムの停止時間となる場合が多い。
という話も聞けました。
DBリファクタリング適用の移行期間を設ける必要があるのはどういう状況か？
- マルチアプリケーションの場合に必要となるケースが多い。
- DBを利用するすべてのアプリがすぐに対応できるわけではないので対応待ち期間を作る。
- そもそもどのアプリが使っているのかがわからないケースがあるので、移行期間を設けて問題が起こらないことを確認するという場合も。
- データ参照しかされないのであれば、Viewが使えることが多い。
- 先にスキーマ変更してから移行期間に古いスキーマをViewで見せるか、新しいスキーマをViewとして見せて、移行期間後にスキーマを更新するかはケースバイケース。どっちでも良い。
ステージング環境は何処まで本番と同じ環境が作れるものなの？
- それクラウドなら(ry
- データに関しては極力本番に近いデータが望ましい。
まとめ
講演、座談会のどちらも内容が非常に濃くて大変勉強になりました。 読書会の運営スタッフの皆さん、会場を提供してくださったOracleの皆さんありがとうございました。
次回は4章の「稼働環境へのデプロイ」についてです。最近、継続的デリバリー という本を読んでいて非常に気になるテーマなのでタイミングがあえばまた参加してみたいです。
