3 ways to approach a Ruby on Rails application upgrade
Upgrading a Rails application is almost never the top priority for a company, but over time it pays to remain up to date. You ensure that bugs and security vulnerabilities get fixed. Plus, new features make future feature development quicker and easier. On top of that, never prioritising an upgrade means that you’ll find it harder to recruit and retain staff. Most developers like to work with new, modern technology and by not upgrading, you are subtly telling your developers that you don’t care.
There are 3 main ways you can upgrade your Rails application to a newer version.
- Stop the bus upgrade
- Porcupine upgrade
- Multiverse upgrade
There are pros and cons to each approach, and the best option for you will depend on a variety of factors.
“Stop the bus!”
Otherwise known as the “big bang”, this approach is where all other development stops to prioritise the upgrade. This is the quickest way to perform an update. For smaller applications, it will be the most cost-effective option if no new significant features are required.
Porcupine
Like porcupines, this approach is large and slow and often a bit spiky. The upgrade takes place on a separate branch, and the developers who are assigned try to keep up with the ongoing development on the master branch. This way, new feature work doesn’t need to stop, but it can be a painful way to upgrade. It often requires duplicated work or re-work and can feel like you’re chasing your tail for a while. If the upgrade is likely to take significant time, then it may be appropriate to continue new feature development. The value of having new features ready sooner will offset the extra time and cost needed to perform the upgrade.
Multiverse
I call this the multiverse upgrade because, in effect, you run two versions of Rails in parallel. It’s definitely more work (and hence cost), but there are several advantages to this route. You can continue to keep most developers working on new features. As there’s no long-running upgrade branch— you run both versions on the main development branch—developers are forced to write code that will work for both versions. This does result in the need to add more conditional code to check the version running and write specific code for each.
But, it also allows you to roll it out in stages because you can dual-boot the application under either version. If your application is large, you can gradually deploy and test it with a proportion of your user population. If a problem is found, you can quickly switch back to the older version.
Once it is working on the new version then a second pass through the application to remove the conditional code is quite straightforward.
Which approach should you choose?
There isn’t a definitive answer to this question. The right solution for you will be a combination of business needs and budget availability. One other big factor to consider is the amount of test coverage the application has (or hasn’t) got. I don’t recommend a multiverse-style upgrade if there isn’t a decent level of test coverage. With other approaches, you can take more time to perform manual tests, but I would recommend at least adding some automated smoke tests for the critical paths to provide more peace of mind.
Need help?
If you’re considering a Ruby on Rails upgrade for your application and you need some help or guidance, we can help. We have been working with Ruby on Rails for over 10 years since before version 2 was released and we have upgraded all manner of Ruby applications. Whether you’re looking for some consultancy for your team or would like us to do it for you, contact us today for a free no-obligation chat.