Zero-downtime Rails upgrades
This course treats a Rails upgrade as a series of deploys, each with a single cause. It sorts breakage into four kinds: load-time, test-time, runtime and data. It explains why data breakage survives a rollback. It covers reading the upgrade guide as a list of greps, sending deprecation warnings to a bounded counter and flipping framework defaults one at a time. It also covers dual-booting two lockfiles on one branch and the expand-contract shape for the two-version window of a rolling deploy. It ends by counting steps and deploys.
What you'll learn
- ✓The four kinds of upgrade breakage and why data breakage survives a rollback
- ✓Turning upgrade guide removals into greps and behavior changes into tests
- ✓Configuring deprecation behavior, including :notify with a counter and :raise in test
- ✓Flipping framework defaults one at a time with load_defaults and the generated file
- ✓Dual-booting with two lockfiles and a second CI job
- ✓The expand-contract shape, read-first format changes and lock_timeout for migrations
What a Rails upgrade actually breaks
An upgrade is four different risks wearing the same version number. They fail at different times, in different places, with different blast radii, and treating them as one thing is why upgrades feel unpredictable.
Read the full lesson free →Curriculum
7 lessonsWhat a Rails upgrade actually breaks
Separates upgrade breakage into load-time, test-time, runtime and data, and shows why data breakage survives a rollback.
Reading the release notes as a work plan
Turns the upgrade guide into greps for removed names and tests for changed behavior, reading every skipped version.
The deprecation signal
Shows where deprecation warnings go in each environment and how :notify feeds a bounded counter during an upgrade.
Flipping defaults one at a time
Explains how load_defaults separates new behavior from the gem version, and how to flip generated defaults one by one.
Dual-booting: two Gemfiles, one branch
Runs the next Rails version from the same branch with two lockfiles, a second CI job and temporary compatibility branches.
The two-version window
Covers the overlap of a rolling deploy, the expand-contract sequence for schema changes, and lock_timeout for migrations.
Zero-downtime Rails upgrades: putting it together
Counts how many deploys each change needs, explains the read-first order, and groups independent steps into shared deploys.