rails-migrationslisted

# Safe Rails Migrations Rails migrations are easy to write and easy to break production with. Schema changes on populated tables can lock rows or the whole table for minutes — enough to time out requests and trigger an incident. These patterns work on PostgreSQL (the common production default); MySQL equivalents are noted where they differ. Start with [[rails-core]] rule 5 (multi-step nullable columns) and rule 6 (multi-DB rollback) — this skill extends those. --- ## 1. `strong_migrations` — catch unsafe operations before they ship Install `strong_migrations` to auto-detect dangerous migration operations at startup. It raises in development and CI for any migration that would lock a production table. ```ruby # Gemfile gem "strong_migrations" ``` After install, run `bin/rails generate strong_migrations:install` — it creates `config/initializers/strong_migrations.rb` where you can configure the production table-size threshold (default 10 MB). Operations it catches: adding a column with a non-null default (on older stacks), adding a non-concurrent index, changing a column type, renaming a column or table, and several others. When `strong_migrations` raises, it tells you the safe alternative. Read the message before adding a `safety_assured { }` bypass — the bypass is for cases you've genuinely reasoned through, not for making the error go away. --- ## 2. Adding a column with a default value **Rails 11+ on PostgreSQL 11+:** adding a `NOT NULL` column with a `default:`