Rails 6.0 is not 3 months old and has had over 600,000 downloads already. In 2019 alone, more than 460 Ruby contributors submitted improvements and fixes. Rails application upgrade isn’t always something companies announce, but looking back at GitHub’s history of being on a custom fork of Rails 3.2, this upgrade is a big deal.
GitHub migration to Rails 6.0
Rails application upgrade, especially for an extensive web application, can be a pain. GitHub is used by nearly 2 million companies and is the #65 most visited website in the world. From a technological standpoint, Rails accounts for most of the service code. Recently they announced Ruby on Rails application upgrade from an old version that they had forked. Let’s deep dive into how GitHub upgraded Rails from version 5.2 to 6.0. It’s quite a unique approach.
Long story short: As soon as GitHub finished the Rails 5.2 upgrade last year, they started upgrading the application to Rails 6.0 (Eileen wrote about the actual process when GitHub upgraded from Rails 3.2 to 5.2). On August 26, 2019, GitHub was deployed to production with 100 percent of the traffic on the newest Rails version: 6.0. This change came just 1.5 weeks after the final release of Rails 6.0.
- They were much more involved in this release than they have been in any previous release of Rails. In fact, GitHub, with Internet giants like Shopify, Basecamp, as well as many other well-recognized companies and applications, have been running the pre-release version of Rails 6 for months and months in production.
- Github added many their core features into Rails while they were upgrading to the newest version. Parallel tests for faster test suite or multiple databases supported by default are the perfect examples. Github didn’t just upgrade their Rails version; they upgraded Rails itself partly. What this describes is co-development of Rails 6 to ensure that it meets the needs of a big, influential user of this OSS project.
Here’s Eileen’s look at the upgrading process
Smooth or never-ending Rails application upgrade?
Perhaps an unpopular take, but what is described by Eileen as “smoother, easier and faster than ever,” on the other hand, seems to refer to an rails application upgrade process that has been going on for over a year. The average Rails consumer cannot afford to run tests against the master continuously. It’s not realistic. That’s true for every mature framework, not just Rails itself.
But it’s excellent for some of the big players in the Rails community to test against their framework’s master branch. If nothing else, that significantly reduces the likelihood of painful upgrade paths (these often happen because of gratuitous API changes that ignore the needs of current users) — knowing that billions of page views have been through the framework irons out so many edge cases. Both bugs and performance issues, and you often get that perk on day 1 when a new release is out because it’s already been running on GitHub for months (and other big sites too).
At last, I should add it’s really wonderful that Github contributed so much to the new release and was so involved. I also appreciate that a company such as GitHub with an older Rails install took the trouble to upgrade to the latest version under development and contribute and help Rails along the way. Maybe they could have waited, but if you are in a lucky position and have the developer resources available, it’s better to be proactive instead of waiting for an official release, and all of a sudden, try to upgrade and run into a lot of unforeseen issues.
Is it worth the headache of upgrading to 6.0?
It is. At the very least, simply because the headaches that accompany those upgrade paths will be significantly bigger once you skip a version or two and finally want to jump to 7.0 or 8.0. Instead, you should upgrade your Ruby on Rails application while it’s relatively painless. I generally agree with regularly upgrading instead of waiting until you’re so far behind that it’s an ordeal.
You don’t want to find yourself in a place where there’s a vulnerability announced, and you can’t pick up a fix without updating Rails to 6.0 version, with all of the headaches that it usually brings. So unless you intend to spin down the app entirely in a couple of years, I’d say it’s worth doing, just for the sake of security updates. As practice shows, it’s worth devoting a few % of the time to migrating everything to the latest Rails version and fixing any issues that come up along the way. Also, consider trying to move objects that had been using external or open-source gems to any new internal processes that cover the same responsibilities.
For any software that isn’t under active development, you aren’t adding new features or generally hardly ever touch it upgrade, of course, it’s not worth it. Just be aware (!) that by not upgrading, you are building technical debt because eventually, your dependencies will be unsupported and nobody will be providing a patch. And they’ll be hard to get running on modern devices and operating systems. Of course sooner or later some other dependency will have severe security vulnerability and will release a fully working fix … in a version that only works in Rails 6.0+.
Rails application upgrade is a perfect time to evaluate the app.
If you’re an experienced Ruby on Rails developer, you know all about upgrading apps from one version to another; it’s part of your job. Rails application upgrade is hard work and can be time-consuming, but they also open up a ton of possibilities. These upgrades can range from simple gem version bumps of 126.96.36.199 to 4.2.6 to nightmarish leaps from 3.2 to 4.1.
Will it make your software faster or more reliable to upgrade to Rails 6.0? I’d say not significantly. But this is how it looks like, and the software works nowadays. By just standing still, you build up technical debt in your organization. Rails 5.1 is already no longer supported in the Rails maintenance policy; they do not commit to releasing patches for severe security vulnerabilities in Rails 5.1. It’s out of support.
On the other hand upgrading Ruby on Rails application gives you a chance to dig into the gems that you’ve been using for a long time, to learn about code reloading and character encodings, and generally to deepen your understanding of Rails, Ruby, and your application’s environment.
It’s a perfect time for the engineering team to step back, evaluate the application, and invest the time in upgrading. Everyone, both new and old members of the engineering team, learn a whole lot about the application that was forgotten, overlooked, can be improved, etc. from going through an upgrade.
Plus, how do you expect to attract new engineering talent to your team if you’re using old technology? If you’re a talented Rails engineer, do you want to go to work on an application that isn’t using new Rails and doesn’t have plans to upgrade? No, you want to be part of a team that is using new technologies and cares about upgrading and staying current.
Hey! Here’s a summary of some of the goodies captured in the release notes, but there are many more than just that. Good luck with your upgrades!