Rails開発初期におけるマイグレーションの扱い方 〜ファイルは増やすな、まとめよ〜
はじめに
Railsで開発を始めると、ついマイグレーションファイルを毎回追加してしまいがちです。
今、まさに私はこのような状況です。
しかし、実は「開発初期（未リリース）」と「本番運用後」では、マイグレーションの扱い方に明確な違いがあることを知りました。
この記事では、様々な技術記事を読んで学んだ「開発初期のマイグレーション整理術」について、自分の学びを備忘録としてまとめます。
結論：開発初期はマイグレーションを修正・統合してよい
開発初期でまだ本番環境にデプロイされていない場合は、以下のような運用が推奨されるようです。
- マイグレーションファイルは増やしすぎない
- 内容が近い変更は1つにまとめる
- テーブル構造を何度も見直すなら、古いマイグレーションを修正して整理する
- 必要に応じて
rails db:migrate:resetで再構築
# DBをリセットして再構築（※開発中のみに使用）
rails db:migrate:reset
本番運用後は絶対に修正しない
一方で、プロジェクトが本番運用に入ったら方針は逆になるようです。
- 過去のマイグレーションは絶対に修正しない（本番DBに適用済のため）
- 新しいマイグレーションファイルを追加して対応
- カラム削除や変更も専用のマイグレーションで対応
# 例：カラム追加
rails generate migration AddColumnToUsers nickname:string
実際にやってみた感想
私自身「毎回マイグレーションを追加するのが正しい」と思っていました。
しかし、複数の技術記事やベストプラクティス集を読んでいると、以下のような考え方が重要であると学びました。
開発初期かつ未リリースの段階では、マイグレーションファイルを適宜修正・統合することで、履歴を整理された状態に保つことが実用的である
実際にこの方針で運用してみると、意外と難しい部分もありましたが、履歴がスッキリしてレビューもしやすくなるのを実感しています。
まだ完全に慣れたわけではありませんが、少しずつコツを掴んできました。
まとめ
| フェーズ | マイグレーションの扱い |
|---|---|
| 開発初期 | 修正・統合してOK、履歴を整理 |
| 本番運用後 | 修正NG、新しいマイグレーションで対応 |
学んだポイント
- 「マイグレーションは増やすもの」という思い込みを一旦疑う
- フェーズに応じた柔軟な運用が大切らしい
- 履歴を整理することで、将来の自分とチームが助かる(いつか経験したい）
おわりに
マイグレーションの運用方針を切り替えるだけで、開発体験が大きく変わると感じました。
初学者のため、まだまだ知識が浅いです。
間違えていたら、すいません。