=================================================
59:データマイグレーションはロールバックも実装する
=================================================

.. maigo:: ロールバックする予定がないからロールバックを実装しなくて良い？

   * 先輩T：この :index:`データマイグレーション` 、 :index:`ロールバック` 処理が実装されてないけど、絶対にロールバックしない想定？
   * 後輩W：はい、ロールバックしないです。本番リリース後にこのデータマイグレーションをロールバックするとマズイので。
   * 先輩T：データマイグレーションのロールバックがあれば、実装中に進めたり戻したりして試行錯誤できるのでオススメだよ。そういった試行錯誤で見つかるバグや考慮漏れも見つかるので超オススメです。
   * 後輩W：本番でロールバックしないなら不要と思ってました。ちょっと実装方法を勉強してきます。

データマイグレーションのロールバックを実装するかどうかは、本番環境でロールバックを実行する予定があるかどうかで決めるものではありません。
本番環境でマイグレーションをロールバックするということは、本番環境へのリリースで何らかの障害が発生した、ということです。
障害が発生してしまったのに本番環境のデータを元に戻せない、という状況は避けるべきでしょう。

データベースマイグレーション機能を持つDjangoなどの多くのフレームワークでは、スキーママイグレーションのロールバック機能を提供しています。
これに対してデータマイグレーションは、正しいデータの状態を人間がプログラムする必要があるため、自動では用意されません。
スキーマと同様に、データもロールバックできるように実装しておけば、何かあった場合の最終手段として利用できます。

もし、データマイグレーションのロールバックが用意されていなかったり、どうしてもロールバック処理を実装できないマイグレーションの場合、本番環境への適用はかなり慎重に行う必要があるでしょう。

ベストプラクティス
=======================

データマイグレーションはロールバックも実装し、動作を確認しましょう。

データマイグレーションのロールバック処理の実装は、本番適用時のトラブルに対する備えであると同時に、データマイグレーションに対するユニットテストでもあります。
ロールバック処理を書くことでデータマイグレーションに対する理解が深まり、事前に問題に気づく機会を得られます。
また、適用とロールバックを繰り返しながらデータの整合性に問題がないか、確認を繰り返し行えるようになります。

:doc:`58-DBのスキーママイグレーションとデータマイグレーションを分ける` で実装したデータマイグレーションに、ロールバック処理を実装してみましょう。
以下のコードにある ``reverse_address_data`` がロールバック処理です。

.. omission::