3 min read

After running the pre-release version of Rails 6.0 for months in production, the GitHub application was deployed to production on its official release last month. Yesterday, GitHub shared how its upgrade team was able to make the transition from Rails 5.2 to 6.0 smoothly just after 1.5 weeks of the release.

Rails 6.0 was released with several amazing features including action mailbox, multiple database support, parallel testing, and more last month. GitHub is not only using it but has also made significant contributions to this release. It submitted over 100 pull requests for documentation improvements, bug fixes, performance improvements. Its contributions also included updates to the new features in the framework: parallel testing and multiple database support.

For many GitHub contributors, this was the first time sending changes to the Rails framework, demonstrating that upgrading Rails not only helps GitHub internally, but also improves our developer community as well,” GitHub wrote in the announcement.

GitHub’s approach to this update was incremental. Instead of waiting for the final release, it upgraded every week by pulling in the latest changes from Rails master and running its tests against that new version. This enabled them to identify regressions quickly and early. The weekly updating process also made it easy to find these regressions because they were dealing with only a week’s worth of commits.

GitHub now plans to use this co-development approach for future releases as well. It wrote, “Once our build for Rails 6.0 was green, we’d merge the pull request to master, and all new code that went into GitHub would need to pass in Rails 5.2 and the newest master build of Rails. Upgrading every week worked so well that we’ll continue using this process for upgrading from 6.0 to 6.1.

Following this approach has not only helped in improving the GitHub application in terms of security, performance, and new features but has also improved the working experience with the GitHub codebase for its engineers.

This sparked a discussion on Hacker News were developers also recommended taking an incremental approach for upgrading one’s application. A user commented, “Incremental updates may require more time to complete, as an API may be refactored multiple times over many versions. However, the confidence in moving incrementally is well worth it IMHO. If you don’t have an extensive enough test suite or poor/missing QA process (or both!), doing a big bang upgrade is going to both be extremely painful and very error-prone. It’s worthwhile to keep up to date. It’s probably not worthwhile to upgrade ASAP after a release, but you don’t want to wait too long.

Another user added, “…they could have waited but if one has the developer resources, 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.

Check out the official announcement to know more in detail.

Other news in web development

GitHub now supports two-factor authentication with security keys using the WebAuthn API

The first release candidate of Rails 6.0.0 is now out!

GitLab considers moving to a single Rails codebase by combining the two existing repositories