Upgrading Ruby on Rails

If you’ve got a Rails project that needs dragging into the modern era and your development team are tied up working on new features or firefighting, we can slot in alongside them and get your application upgraded.

Introducing Codeface, the UK Rails experts

Codeface has been working with Rails for over fifteen years. Over those years we’ve performed dozens of upgrades on Rails projects.

We’ve experienced the pitfalls, learned a few tricks along the way and come up smiling to the tell the tale.

Why upgrade?

If you’ve landed on this page, we’re probably preaching to the converted, but here’s a reminder of some reasons why it’s worth getting a Rails project up to latest and greatest versions:

Security, security, security - only the last 2 major versions of Rails typically get security patches released, so it’s worth staying on top of things and not letting your project drift into the land of unsupported versions.
Happy developers - your development team would love the project to be on the latest version of Rails, but they just don’t have time to take care of this upgrade job.
Access to latest features - that whizzy new function in the site you were imagining…it might just be a lot easier to implement using some of the more recent features of Rails that weren’t around when you started several years ago.

As well as those key reasons above, some of the happy side effects of getting your Rails project upgraded by Codeface are:

In order to get up and running and get the project upgraded, as a first step we will often improve the on-boarding process for new developers. Who better, and when better to do this - we’re new to your project, so, we’re ideally placed to get to grips with how your project works and how it’s configured with a fresh pair of eyes, and whip it into shape so that we and any future developers can get up and running quickly.

A lot of projects that have accumulated baggage over the years can take hours for a new developer to get up and running for the first time. Our rule is if we can’t run the project from a standing start in 2 minutes, something needs sorting out. And we’ll sort it.
Test coverage - we can evaluate and improve your automated test coverage as part of the upgrade project (more on this below)
Documentation - in the process of getting to grips with your project, we can produce documentation that will help future developers.

Rails’ rich history

Many of the Rails upgrades we’ve performed recently were Rails 5 up to Rails 7 - now that Rails is a mature framework these migrations can often go pretty smoothly with minimal fuss.

But we’ve also done a fair few upgrades from Rails 4 recently and even a couple starting from way back on Rails 2 and Rails 3. Rails 2 was released way back in 2007 around the time we first discovered Rails. That’s 17 years and counting of Rails’ rich history to navigate when performing an upgrade.

Transitioning from older versions of Rails can be a bit more involved, but we’ve built up enough experience to be able to take care of the issues that can arise.

Getting Ready for Rails 7.2 and 8.x

Rails 7.2 beta is now out. If you’re serious about keeping your web app up to date, get ahead of the game and get Codeface to get your Rails 7.2 ready.

Rails 8 development started at the same time and we’ll be keeping an eye on development so that we can hit the ground running when the first sneak preview of Rails 8 is released.

Automated testing

If your Rails project already has some good test coverage with rspec or minitest or one of the other testing frameworks, then you’re halfway there already.

If you don’t have a test suite and if your Rails app takes more than a few seconds to test, we’ll recommend that we get some test coverage in place before we start the upgrade work. Creating tests for an unfamiliar project is also a great way for us to get up to speed with how everything works (and document things as we go). Time spent creating automated tests is never time wasted.

Once tests are in place, they’re there for the long term, and we can help you set up CI/CD so that the tests get run at appropriate times liken when your developers push new features, or merge new features into the main/master branch.

Get in touch

We’d love to hear from you.

This page was handcrafted in Brighton by Codeface