Staying Ahead of the Rails Curve: Cultivating a Culture of Continuous Upgrade for Company Success

Most people and companies that we talk to about upgrades assume that we generally help organizations that need to migrate to the latest Rails version.

However, this isn’t necessarily the truth. Instead, we mostly perform Rails upgrades for companies who are all the way back on Rails 3 or 4. To give you a better understanding of how common it is for companies to be on much older versions, this is a general list of our statistics from the past few years.

• Rails 2.3 - 3.2: 5 - 15 upgrades
• Rails 3.2 - 4.2: ~40 upgrades
• Rails 4.2 - 5.2: ~40 upgrades
• Rails 5.2 - 6.1: ~10 upgrades
• Rails 6.1 - 7.1: ~10 upgrades

We generally work with a lot of large, well established companies, so how did these successful companies fall so far behind, and how can you help your company to never need to hire us?

Why is it important to be on a newer version of Rails?

Here is a list of the top reasons clients come to us with sudden needs to upgrade their applications:

1. Compliance and security reasons
2. Bug fixes
3. Performance
4. Wanting to use the new features of Rails

Building in a culture of staying up to date.

In this article we want to focus on creating a culture in your company about the importance of reducing tech debt and keeping up to date with a gradual approach.

For more tips on staying up to date with certain tools and practices, you can check-out our How to Stay Up to Date with Your Rails Application opens a new window article.

Make your own rules and follow them.

The most important thing we want to mention is building upgrades straight into your process; draw lines in the sand early on, or right now, even if you are already far behind.

Have an agreement with your product team, CTO, or anyone in between from whom you’d need to get buy-in.

For example, agree to be no further than one minor version behind the current release of Rails. If you need to reason with your higher-ups on why this is important. Check out our How to Pitch a Rails Upgrade to Your Boss (Without Any Tech Speak) opens a new window article.

Then, when there is going to be a new version release, it means it’s time to devote developer hours to upgrading to the next version. At this point, it should be a nonnegotiable because you already have firm lines in place, stating when you will upgrade.

Make it a slow, do-able process

If you have followed our advice and you are not many versions behind, you shouldn’t need to upgrade on a specific scary timeline. Your company should be able to take its time going to the next version.

If your team hasn’t already, it’s time to start fixing the current deprecations warnings. However, we advise that these should be fixed over time, even before you were planning to go to the next version.

For example, in every sprint or planning meeting, you could allow for one type of deprecation to be fixed. Once they are fixed, you can follow our advice in the Safeguarding from Deprecation Regressions During an Upgrade opens a new window article to keep your team from re-adding the same deprecations.

Once deprecations are finished you can setup dual boot opens a new window and break down the failures that you find. You will be able to create stories surrounding these failures, and get ready to upgrade a little at a time.

The culture and importance of tests

Build in time to make sure that every new feature, or even bug fix if necessary, has good, solid testing attached to it. The MOST important thing we have noticed over the years, is that the quality of a test suite directly impacts the speed and smoothness of software upgrades.

It may take your developers extra hours during a sprint to make sure that good tests are being added to their code, but the time that is saved in the long run is immeasurable.

With low test coverage opens a new window manual testing could take weeks. With tests that test implementation instead of what the code is achieving, you may spend all of your upgrade time upgrading tests instead of code.

These expectations should be made clear to both developers and reviewers. Include tests in your Definition of Done, build checklists into your pull request templates. Use test coverage tools, like SimpleCov opens a new window and don’t ignore the results. Build regular checks of them into the team’s patterns.

In general, encourage your developers to follow patterns, and strive for consistent code that will be easier to upgrade if necessary.

Conclusion

Building upgrades and gradual processes into your overall flow will save you time, money, and developer frustrations. We know upgrades are hard, especially when you are dealing with code and gems that are many years old. We also know that it is difficult to stay on top of these things, and easy to begin to fall behind.

We can help you get up to speed opens a new window if that has happened to you. Once you are up to speed we would love to help you build in some of our tips to stay ahead of the curve.

Already ahead of the curve? That’s great! If even after reading this you’re still afraid you might end up falling behind, or you’re concerned about other forms of technical debt, we can help you stay ahead with our monthly maintenance services opens a new window .