Happy Bear Software

Keep your Rails application up to date

Patrick McKenzie posted about how businesses that use Rails 2.3 should move to a supported option as soon as possible. I agree with him. If you're on 2.3, switching to the supported fork is the right thing to do.

At the same time, many developers justify a lack of a plan for upgrading applications that are under active development. Sticking to an old version of Rails needlessly hamstrings you, your development team and ultimately your business.

The business value of keeping up to date

We don't need the new features in Rails, so it's not worth upgrading.

Assume for a moment that this is true. Assume that features like the asset pipeline, strong parameters and using bundler to manage dependencies are not worth the time to upgrade.

Here's what you get if you stay up to date aside from the newest features:

Big bang upgrades are horrifying

Do you take good care of your teeth?

Alice doesn't keep very good oral hygeine. She brushes her teeth once per day and hasn't visited a dentist in years.

Bob on the other hand brushes twice daily and flosses every day. He visits the dentist once every six months for a checkup and takes good care of his teeth.

When Bob visits the dentist, he gets a little polish for the areas he can't reach. The visit is painless. He's in and out of the chair in less than ten minutes.

When Alice visits the dentist for the first time in years, she needs to be anaesthetized and leaves with a mouth full of blood. Even with the drugs, this is an excrutiating process that takes up to half an hour, and probably has to be repeated a few times.

Bob's oral hygiene regimen and his regular appointments are not as bad as one of Alices sessions in the chair. The big bang cleanup is a lot more painful than the aggregated overhead of regular maintenence.

The metaphor bears fruit when applied to keeping your Rails project up to date. Sticking to old versions of Rails forces you into corners where you forego the help of the community and dig yourself deeper and deeper into technical debt. Without upgrading regularly, the following risks in eventually upgrading get worse by the day:

The more of an upgrade gap you have to cross, the higher each of these risks are. If you're upgrading a single minor version, it's easier to isolate the cause of observed bugs, both in your application and your dependencies.

A sane upgrade policy

The more often you do this, the less painful each upgrade it will be. Having one person own the process (for a given upgrade) makes it easier to ensure it will get done, but the team should all be pro-getting the codebase up to the latest version.

Following this sort of upgrade path in small, regular bursts of work is much less painful than finding yourself in an unsupported, unmaintainable codebase three years from now.

There are strategies for making the upgrade through a larger gap than minor versions but they're all about as much fun as having a dentist carve the inside of your mouth open. The best way to mitigate that situation is to not be in it.

- Najaf Ali

Find this article useful? Sign up to our mailing list to get updates like this in your inbox every week. No spam, and you can unsubscribe at any time.
Give me the goodies