It’s already been more than a year since Rails 5.0 was released — in fact, Rails 5.2 is now around the corner. Some of you may still be using version 4.2.x and feeling good about it. There’s nothing wrong with you. On the flip side, in my opinion, you should consider the migration. Below are some of my thoughts on why companies need to do it.
Security
The recent incident with Equifax should teach us about the importance of permanent security updates for your framework. In their case, the Struts vulnerability was disclosed and fixed in March, 2017. According to their press release, the unauthorized accesses started happening from May 13, 2017. They had two months to upgrade their version of Struts. This neglect of security practices had catastrophic consequences.
Rails is a mature framework and its team specializes in providing timely new releases with security updates.
Rails maintenance policy states that only severe security issues have been fixed in the previous version of Rails (4.2.Z as of today). Less critical security issues have been resolved only for 5.0.Z and 5.1.Z. If you are reading this post when Rails is already at version 6.*, then Rails 4.2.Z is definitely not patched.
Tip: you can use tools like Brakeman to notify you when you are using an outdated Rails version. I also recommend adding such a check into your CI/CD pipeline.
Another tip: do not forget to regularly upgrade your Ruby version as well, for the same reason.
New Features
Another reason to upgrade your software is that Rails 5.* (5.0, 5.1) has a lot of interesting new features to look into, like ActionCable, Rails API, system tests, JavaScript related improvements, to name a few. In addition to adding new features, Rails has greatly improved its existing features.
Additionally, Rails has a huge ecosystem with lots of different gems that help you develop your application faster. If you are stuck with an old version of Rails chances are that some of new gems / new gem versions are not available for you.
From time to time, Rails contributors introduce some pretty little enhancements that can make your code cleaner, such as new libraries that help you follow the DRY principle. For example, recently I’ve discovered a pull request that is part of Rails 5. Instead of rescuing ActionController::RedirectBackError error in your controllers, you can just use the redirect_back method with a fallback url as argument. It’s needed for cases when there’s no referrer url in a request. Rails just does not know how to redirect user “back” in this case. Changes like this make your code much cleaner and much more understandable.
Framework Bugs
Rails is created by people and people make mistakes. The framework has a great community and as a result bugs are addressed quickly. Sometimes a bug in your application can remain unnoticed for a long period of time, until you have a bug report. Some bugs can be quite tricky, like file autoload in a multithreading environment. You can spend days agonizing over a problem just to discover that the bug is in Rails or in a third party gem and it was already fixed.
Keeping Your Code in Good Shape
For me this is the most important reason to migrate. Having an application that cannot be migrated to a new version of Rails is a sign of even a bigger problem.
What usually holds companies back from migrating? The most frequent fears are:
- Fear of breaking an application. “We’re not sure the application’s behavior will be exactly the same after migration”. This is clearly a sign of a poorly tested system, probably with subpar test coverage. In this case a migration should become part of a bigger project involving code coverage improvement and documenting the system behavior. Sometimes the famous Bus Factor rears its ugly head. Again, it’s a red alert that must not be ignored.
- Lack of time. Let’s face the reality: there are often ongoing projects that are extremely important for the company. Their business value is often much higher than the upgrade. No one wants to sacrifice business opportunities to build a perfect system. Maximizing the current business value is the top priority. On the other hand, technical leaders should negotiate appropriate time for migration and add it to the calendar. It should be a prioritized and scheduled project. Otherwise, adding new functionality will become more and more painful, causing the business value to suffer. In a properly maintained application, such a migration can take from several days to several weeks — it should not take months.
- “This is a large undertaking for us — we did not upgrade for years, and now it’s too hard to do it.” See above. This is the situation we want to avoid. Due to lack of time or some higher priority projects the company did not find time to upgrade and, essentially, accumulated technical debt. Now is the time to pay off.
I hope I was able to demonstrate that typical fears of Rails upgrade usually do not exist alone. In most cases they are the sign of general technical debt accumulated in years.
Conclusion
Upgrading to a new version of Rails should be a regular activity — it can reduce technical debt and help to prevent security issues. It’s definitely worth investing your company resources in a Ruby migration.
