It’s already more than a year since Rails 5.0 was released. Actually, Rails 5.2 is already around the corner. Some of you may still be at version 4.2.x and feeling well 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.
The recent incident with Equifax should teach us about importance of permanent security updates for your framework of use. 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 led to catastrophic consequences.
Rails is a mature framework and their team is really good at timely releasing new versions with security updates.
Rails maintenance policy states that only severe security issues are fixed in the previous version of Rails (4.2.Z as of today). Less critical security issues are fixed only for 5.0.Z and 5.1.Z. If you are reading this post when Rails is already at version 6.* Rails 4.2.Z is not patched for sure. Tip: you can use tools like Brakeman to notify you when you are using 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.
Also, 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 high that some of new gems / new gem versions are not available for you.
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 not noticed for a long period of time and than you have a bug report. Some bugs can be quite tricky like file autoload in multithreading environment. You can spend days just to discover that the bug is in Rails or in a third party gem and it was already fixed.
Keeping your code in a 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 from migrating? The most frequent fears are:
- Fear of breaking an application. “We are not sure that application’s behavior will be exactly the same after migration”. This is clearly a sign of badly tested system, probably with poor test coverage. In this case a migration should become just a 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. The application has some parts that no one is aware about.
- Lack of time. Let’s face the reality, there can be ongoing projects that are extremely important for the company. Their business value can be much higher than the upgrade. No one wants to end up with a perfect system but with lost business opportunities. 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, thus business value will suffer. In a properly maintained application such a migration can take some time from several days to several weeks, but not several months for sure.
- “This is a large undertaking for us, we did not upgrade for years, now it’s too hard to do it”. Yeah, 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.
From time to time Rails contributors introduce some pretty little enhancements that can help you to make code cleaner and not reinvent a wheel by introducing some libraries that help you in following the DRY principle. Just one small example. Quite recently I’ve discovered a pull request that is the part of Rails 5 now. 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.
Upgrade to a new version of Rails should be a regular activity and it can help in prevention of security issues and reducing technical debt. It’s definitely worth investing your company resources.