Zero downtime Rails upgrades
summary
Claim: upgrades happen with zero downtime by making them incremental, measurable, and repeatable. Steps: target the next minor version, fix deprecations per file and fail tests on regressions, add dual‑booting so main runs old and new Rails, backport new APIs (strong_parameters example) to let teams adopt patterns early, group and fix test failures in chunks, and run small production experiments—canaries at 5–40% traffic—until errors drop. This is implemented at GitHub and other organizations and it works.
AI-written summary · about
chapters (10)
- 0:00Rails upgrades introduction
- 2:50Why upgrades feel hard
- 5:40Treat upgrades like features
- 8:49Smaller versions
- 13:23Fix deprecation warnings
- 16:54Avoid long branches
- 19:46Backport new Rails features
- 23:59Group test failures
- 26:49Test in production-like envs
- 30:25Repeatable upgrade process
related talks
29mUpgrading Rails at Scale
28mUpgrading Rails: The Non-Technical Parts
39mZero downtime deploys for Rails apps
25mUpgrading Rails: Everyone can do it and here’s how
35mChanging the wheels on the bus at 80 mph: Upgrading to Rails 3
32mZero Downtime Deploys Made Easy
36mRuby & Rails Versioning at Scale
38mThe Past, Present and Future of Rails at GitHub