Djangoのマイグレーション戦略
DjangoなどのWebフレームワークには、DBのスキーマを変更するマイグレーション機能があります。一般的に、プログラムを実装するときはリポジトリでブランチを作りそれぞれのブランチで実装作業を進めます。Djangoアプリの開発でも同様ですが、各ブランチでDBスキーマを変更する場合には注意が必要です。例えば、複数のブランチで同じテーブルのカラムを追加して使いたい場合や、DBスキーマの変更が競合する場合は、ブランチのマージ時に競合してしまいます。多くの機能を並行開発したり、マージするまでの期間が長い場合には、このような競合が増えてしまいます。
DBスキーマ変更が競合するシンプルな例
実際の開発現場で発生したトラブル事例
DBスキーマ変更の先行リリース
新旧DBスキーマの並行運用
参考
> アプリケーションのデプロイだけでなく、DBのマイグレーションやロールバックまで含めた実践的、実用的なCI/CDの参考資料ないかな。
> アプリケーションのロールバック時にDBまで自動でロールバックさせてるところってどれくらいあるんだろう。そして、その人たちはどうやって実現してるんだろうか。
> Kosei Kitahara @Surgo 4月15日
> DB のマイグレーションは単発リリース。アプリケーションの変更は後。とかでやっていたります。
> Takayuki Shimizukawa @shimizukawa 4月15日
> それ、運用しながら平行開発してるとよくやりますね。
> テーブル構造変更のときは、新旧両方にデータ保存してロールバックしても大丈夫にしておくとかやりました。旧の削除は数週間様子見てから実施。
> 新旧両方にデータ保存というのは具体的にどういう仕組みで行ってましたか？パッと思いつくのは新旧2バージョンのアプリにリクエストをコピーして渡す、アプリのロジックで両方に保存する、データ保存処理をフックする辺りでした。（3つ目はテーブル構造自体が違うと大変そう笑
> Kosei Kitahara @Surgo 4月15日
> * 新旧双方突っ込むアプリをリリース (参照は旧カラム
> * 旧カラムデーター突っ込まないアプリをリリース
> 細かくいうと間に NULL 制約、NOT NULL 制約のマイグレーションリリースなども挟んだり。。
> なるべくアプリのリリースとスキーママイグレーションのリリースは分割してロールバックを防止するのが良さそうです。
トークプロポーザル