The Long Ball - Upgrading long lived Rails apps from 1.x-4.0
summary
Case studies show stepwise upgrades from 1.2 → 2.3 → 3.0 → 3.1 → 4.0 with concrete actions: pin gems and add Bundler for 2.3, rewrite router/JS/query code for 3.0, fold CSS/JS into the asset pipeline for 3.1, and adopt strong parameters and gem updates for 4.0. Authentication moves to bcrypt via Devise or Sorcery, Prototype-era apps can use prototype-rails as a bridge, and a published rails upgrade checklist maps tasks into deployable increments that demonstrably succeed.
AI-written summary · about
chapters (38)
- 0:00Introduction
- 1:33Legacy apps
- 2:03Rails is not WordPress
- 2:23Rails code is constantly changing
- 2:48Rails code is volatile
- 3:07Rails is constantly evolving
- 3:28Why evolve
- 4:34Old Rails apps
- 5:03Rails app lore
- 5:25Railsjs
- 7:19Source Control
- 7:46Flash Forward
- 8:03Rails 23 App
- 9:09Rails 23 API
- 9:48Rails 3 Point Out
- 10:00Rails Query Interface
- 10:34Active Model
- 11:13Routes
- 11:30Asset Pipeline
- 12:19File Hash
- 12:34Speed
- 12:49Pluck
- 13:49Postgres
- 14:55Upgrading
- 16:05Why rewrites fail
- 17:48Keeping product momentum
- 18:13Users dont care
- 18:47PHP on Rails
- 19:41Vendor Gems on Rails
- 20:47Refactoring
- 21:28Main upgrade pains
- 21:39Main upgrade points
- 28:01Recap
- 28:16Tips
- 32:23Authentication
- 34:18Always upgrade
- 36:33Checklist
- 36:52Rails Upgrade Checklist
related talks
28mUpgrading Rails: The Non-Technical Parts
21mRails Upgrade Mastery: Best Practices for Large-Scale Enterprise Applications
26mLet the Junior Dev Upgrade Rails
38mOur Fight Against Super Bad Patterns in Legacy Rails Apps
25mUpgrading Rails: Everyone can do it and here’s how
33mUpgrading a big application to Rails 5
29mUpgrading Rails at Scale
36mRuby & Rails Versioning at Scale