DISCLAIMER

This is not a how-to post. There are plenty of those out there targeted at migrating from whatever version you are on to whatever the next version for you happens to be. Ombu Labs helped us out and they have written a bit on the topic of upgrading.

This is highlighting our application as an example of one that has successfully been upgraded over time.

At one point it was hard to believe we'd make it. Fortunately, each upgrade does seem easier. But if you stagnate too long, the buildup of multiple releases becomes quite intimidating.

Many other companies have done this. Likely the highest profile site is Shopify.

Once upon a time

Our application, Nitro, began around the end of 2007 as a Rails v1.2 application. Our first official git check-in wasn't until almost a year later on October 30, 2008 when we switched from subversion.

Our initial git checkin

From Rails v1 to v2

The history of that upgrade is lost in the depths of our abandoned subversion repository. I did find the following note I left about it.

It was a quick upgrade.

Which refers to us getting to Rails v2.1 in the beginning of June 2008. Our code base wasn't very large back then so there wouldn't have been much to change.

If you still have a Rails v1 app rolling around somewhere today, I would guess that your best option would be to rewrite it rather than go through the upgrade process.

From Rails v2 to v3

In May 2012, we started an upgrade to Rails v3.0. This upgrade introduced the concept of an html_safe string and probably 80% or more of our commit messages contain something like Added html_safe to whatever.

Based on our commit history in git, this process took us around three months to complete. This was in the midst of other work we had to do, so it wasn't a dedicated effort.

After we completed that, we upgraded to Ruby 1.9 in September 2012. We were also still fixing left-over issues with html_safe here and there in less frequently used areas of our app.

We upgraded to Rails v3.1 in the first part of 2013, followed by Rails v3.2 around June 2013.

From Rails v3 to v4

Rails v4 was ramping up for a release in 2013 at the time we got our app to Rails v3.2. We talked about investigating the upgrade path to see about upgrading.

Upgrading Rails was much less of a priority than the growing needs of the business. We didn't know it at the time but we were embarking on a very long dry spell void of any framework upgrades.

It wasn't until the beginning of 2017, at a point where Rails v5 was out in the world, when we realized we were missing out on too much and Rails v3.2 was holding us back.

We needed to get up-to-date.

We brought in an outside team with experience upgrading Rails applications and dedicated them along with a senior developer from our own team to get us back to current again.

Our goal was Rails v5.1 and we weren't going to stop until we got there.

By March 2017, we were on Rails v4.0 using Ruby v2.3.3.

Here are the main areas of pain we had, mostly due do the size of our application which now supports a database of 550+ tables.

  • gem incompatibilities
  • deprecations like dynamic finder methods (.find_by_...)
  • changes in how scopes were changed
  • strong parameters
  • changes to Rails routes

From Rails v4 to v5

2017 was a very busy year for upgrading. Our app was running on Rails v5.1 by the end of the year.

Date Rails Version
March 5 4.0
July 17 4.1
July 19 4.2
October 17 5.0
December 3 5.1

Here are the main items we had to contend with in getting to Rails v5.

So far in 2018, we've upgraded Ruby to v2.5.0. Later in the year, we'll look at moving up to Rails v5.2 once it's been out for a bit.

This time, though, we don't plan to fall behind much more than a single release.

rails-upgrade-timeline-a-1

This article is cross-posted at the Tech at Power blog.