Changing the wheels on the bus at 80 mph: Upgrading to Rails 3
summary
New Relic upgrades Rails by running Rails 2 and Rails 3 from one master branch while 55 engineers keep committing; two maintainers patched Bundler to support two lockfiles, build a backwards-compatible boot sequence, and shim ActiveScaffold and other gems. The team sees roughly 1400 commits deploy without disruption, runs CI jobs for both runtimes, fixes session/JS/instrumentation quirks, and rolls a canary before flipping production. The approach works with measurable but small postdeploy firefighting.
AI-written summary · about
chapters (30)
- 0:00Start
- 1:06Overview
- 3:58Upgrading to Rails 3 1. Procrastinate
- 10:05Upgrading to Rails 3 Procrastinate
- 13:59Make it easy for everyone
- 14:33Unbreak Rails 2
- 15:12Onto master
- 16:50config/application.rb
- 17:56Have tests you trust
- 18:15Use C
- 19:03Upgrade dependencies on master
- 19:35Backgroundjob to Resque
- 20:16Add an abstraction layer
- 20:29Use Resque or Backgroundjob
- 20:54Branch by abstraction
- 22:57Your error handling (can) still work
- 24:10Extensive manual testing
- 24:42Make everyone a tester
- 25:05Tum on Rails 3 by default
- 25:57Incompatible sessions
- 26:57Deploy a canary
- 27:16Pause the world
- 27:45Deploy all the servers
- 27:59Oops
- 29:32Breaking the audit trail
- 30:32Rushed Resque rollout
- 30:55Punching ActiveScaffold in the face
- 32:14Tagging green build off of Rails 2 tests
- 32:59Lessons learned
- 33:45The special magic pony sauce
related talks
29mUpgrading Rails at Scale
21mRails Upgrade Mastery: Best Practices for Large-Scale Enterprise Applications
28mUpgrading Rails: The Non-Technical Parts
33mUpgrading a big application to Rails 5
22mRiding Rails for decades
36mRuby & Rails Versioning at Scale
36mRuby & Rails Versioning at Scale
26mLet the Junior Dev Upgrade Rails