The Past, Present, and Future of Rails at GitHub
summary
GitHub documents upgrading from a custom Rails fork to Rails 5.2, with deployed 5.2 to production with zero downtime after a coordinated effort: two six‑month and five‑month upgrade phases, teams of about four full‑time engineers plus volunteers, and a dual booting CI approach to run tests against old and new Rails concurrently. The effort costs years of work but yields payoffs: reduced security debt, easier hiring, and 75 pull requests to Rails 6 contributed after the upgrade.
AI-written summary · about
chapters (16)
- 0:00Intro
- 0:18CLOUD Pain Free Rails 66 Deployments
- 0:50I'm a Staff Engineer at GitHub!
- 2:01Upgrading TRAILS at GitHub
- 17:10The cost of not upgrading is immeasurable
- 20:16REWRITE IN MICROSERVICES DEVELOPMENT BACKPORTS
- 22:14When upgrading you should...
- 24:13fix deprecation warnings early.
- 24:53When upgrading you should plan for the future.
- 26:29falling behind security supported versions.
- 27:05using old, unsupported gems.
- 30:29The benefits of upgrading
- 34:50Rails 6.0: Multiple database support
- 35:18Continuous Upgrades
- 36:07We're pioneering the future of Rails.
- 36:36We have a responsibility to support Rails
related talks
38mThe Past, Present and Future of Rails at GitHub
38mThe Past, Present, and Future of Rails at GitHub
42mThe Past, Present, and Future of Rails at GitHub
33mUpgrading a big application to Rails 5
06mGitHub - Tal Safran
28mUpgrading Rails: The Non-Technical Parts
29mUpgrading Rails at Scale
22mRiding Rails for decades