I was recently tasked with upgrading our Ruby on Rails application at work: my goal was to move two major versions up, with a middle step on a minor version (and a server OS upgrade that was not even planned!). This was an incredible experience and I learned a lot from it. Here are some take-aways I can share:
Write tests
This project has a robust test suite. It doesn’t have full coverage – not even close! – but all the main functionality has tests. This proved very helpful during the upgrade process: very often I would get my app in a “running” state, only to find out later that several tests were broken. Without the tests, these issues would only be found during QA or even worse, in production. Yikes!
Keep your gems up to date
This is a lot of work, I know. Any given Ruby on Rails app will have a fairly long Gemfile. But trust me, it’s a very good idea to periodically check for any updates on your current gems: it helps immensely when the framework needs to be upgraded. This is one lesson I will implement from now on.
Read the release notes
When a new version is released, go check the release notes, even if you don’t have immediate plans of upgrading. This will keep you familiarized with what is new and what is going away. You can plan ahead and start tackling minor prep tasks before upgrading.
Remove deprecation warnings
Linked to the previous points, actively checking for deprecation warnings and refactoring your code prior to going for a full upgrade will pay off in the long run. Deprecation warnings are a preview of what’s going away in the next version and it’s much better to deal with them separately from the upgrade itself.
Upgrade often
There’s not much more to it. Just upgrade often. Don’t wait until the framework is two major versions away to work on it. It will be painful. I know, I just had to do it.
Note here: I understand that there are many constraints involved into upgrading a project and I also understand why the project at work got so much behind. Still, as far as it’s possible, don’t delay upgrading!
Do a full regression test afterwards
After major upgrades like the ones I just described, make sure that your code base will go through a full regression test. Once again, this is tricky and the organization you work for might not have the resources (a dedicated QA department, for example) or time to fully test it, but as far as possible, make sure to highlight the importance and fight for a full regression test before sending the new version to production.
Conclusion
Set aside time to deal with technical debt. It is as much important as developing new features. And I didn’t even touch on security risks of running an outdated application! If time and resources are short, at least work on the project’s dependencies. Just don’t postpone.
Do you have any important lesson you learned on a similar project? Let me know on Twitter!
The post _6Lessons learned from upgrading a Rails app was originally published at _flaviabastos.ca
Photo by David Herron on Unsplash
Top comments (1)
Can't agree more. We have upgraded our rails recently too.