Now that the final release of Ruby on Rails 5.0 is on the horizon, it’s a good time to start preparing your Rails applications for an upgrade. Here are some tips that should help you get your apps ready.
Photo Credit: HBO, “The Game of Thrones”.
It’s most desirable during the upgrade process to have good test coverage of the whole application, especially with integration tests, as it will help you quickly identify any issues with your upgrade.
If you currently don’t have adequate test coverage, consider starting to write several integration tests now. You should have the test to cover your user’s crucial interaction. For example, if your application is an online store, you should at least have a test for a user completing the purchase process and managing their account.
Rails 5.0 will require at least Ruby 2.2.2. However, given Ruby 2.3.0 is the latest stable version of Ruby, it’s better to upgrade your application all the way to Ruby 2.3.0 instead.
Unless you’re upgrading from an ancient version of Ruby, this process should be simple and straightforward, provided you have good test coverage.
Note that upgrading to newer version of Ruby may cause your application to use more memory, so you should monitor your application’s memory usage after the upgrade.
It’s a good idea to upgrade your dependencies to the latest version, or at least the latest minor version of each dependencies’ major version. With a good version requirement, this could be as easy as running
bundle update. Doing so will ensure that upgrading them again for Rails 5 compatibility should be a breeze. It’s also generally a good idea to keep your dependencies up-to-date, as it might introduce some bug or security fixes that you have missed.
If you are using a forked version of the gem, you should revisit your forked version and see if you can go back and use a public release version. If not possible, you should try to merge those upstream changes to your fork. Submitting a patch to that project is also a great idea, as it’s possible that your patch is going to fix a problem others are suffering.
While it’s not recommended to run a beta version on your production environment, trying out the beta version on a separate branch will let you know what you are getting yourself into if you have some time and resources. It can also help identify potential upgrade pitfalls so you have time to prepare changes to you application to make upgrading as smooth as possible.
However, keep in mind that some functionality in Rails can change dramatically from one version to another during the beta period. You can also wait until the release candidates are out (denoting by
.rc in the version name) before trying it out.
Apart from the time you spend on fixing your code for compatibility issues, which should take about 1-2 weeks with sufficient test coverage, you should plan for 1-2 more weeks of QA work as well. While sufficient acceptance test coverage should guarantee that your upgraded app is working, it’s still a good idea to have someone going in and poking around in the app to see if there are other places that are broken and not covered under tests, and to see if new acceptance tests should be introduced or not.
If your team is limited, it might be a great idea as well to bring in an external consultant team to help with your upgrade process, especially with some complicated upgrade involving upgrading from a legacy version. I have upgraded several Rails applications in the past, and I found out that the experience of upgrading previous app helped me on upgrading the new apps. If that interests you, let us know.