マスタデータの更新を、db/seeds.rb ではなくマイグレーションファイルでやってしまった案件で私が体験した地獄を紹介します。

まずは前提から

・タスク管理アプリの機能追加案件
・task_categories テーブルがマスタデータとして存在する
・マスタデータが変更されたら、都度マイグレーションファイルで ActiveRecord::Base.connection.execute で更新する運用
・マスタデータは db/seeds.rb でも設定している
・task_categories のテーブル構造（一部抜粋）
　・code カテゴリ識別名 (new、todo、finished 等) uniq成約あり

何が起きたか？

マスタデータ更新時に、マイグレーションだけ追加して db/seeds.rb をメンテナンスしていなかったために、
dbを新規作成してrake db:seed を実行すると、uniq成約に引っかかりエラーで落ちるようになりました。
また、db/seeds.rb がメンテナンスされてないため、ソースを見ても何が正しいデータなのかわからなくなりました。（コンソールなどで直接データを覗かないと正しいデータがわからない）

そのとき起きたやり取りを簡単に再現します。

上司「俺君、次はタスク管理アプリの改修案件を着手してくれ。環境構築手順はドキュメントにかいてるからそのとおりでよろしく。」

俺「わかりました。」

~数分後~

俺「すみません、手順書通りに rake db:seed やったらエラーで落ちました。」

上司「悪いけどエラー原因調べてくれない？」

~数分後~

俺「ユニーク成約に引っかかってました。マイグレーションで task_categories のマスタデータを追加・更新した後に、 rake db:seed で同じ code のレコードを追加しようとしたためにエラーになったようです。」

上司「すまないけど、マイグレーションで作成したデータをもとに db/seeds.rb を集成してくれ。」

俺「え、でも task_categories のレコード数死ぬほど多いので大変ですよ。」

上司「頑張ってくれ。」

あとがき

今回は説明をシンプルにするためにテーブル数1つで解説しましたが、実際にはマスタデータのレコード数が多いだけでなく、アソシエーションが孫階層までつながってたので、芋づる式に 4桁分のレコードの db/seeds.rb を書き換える羽目になりました。コードの行数だけでいうと5桁の変更がありました。
流石に手動でそこまで変更するのは無理なので、スクリプトを組んで良しなにやりました。
とはいえ、あまりにも変更箇所が多すぎてスクリプト実行中にメモリ不足で落ちる、差分が多すぎてgitlabで差分が表示できない等、別の苦労もありました。

この記事が少しでも多くの人に見てもらい同様の被害が少しでも減ることを祈っております。