WatersWorks

Blog archive

GitHub's Ruby 2.7 Upgrade Journey

GitHub's upgrade this year to Ruby 2.7 was a massive, months-long undertaking that required a serious investment in engineering resources and time. The team maintaining the popular Microsoft-owned code-hosting-and-collaboration platform recently shared some of the details of that transition, which, among other things, required that they fix more than 11,000 warnings.

"Fixing that many warnings, some of which were coming from external libraries, takes a lot of coordination and teamwork," observed Eileen M. Uchitelle, a staff software engineer at GitHub and core Rails team member, in a blog post. "In order to be successful we needed a solid strategy for sharing the work."

Ruby 2.7 was released last December; the GitHub team completed the upgrade this summer and deployed to production in July. The team completed a major Rails upgrade almost exactly two years ago.

"Upgrading Rails on an application as large and as trafficked as GitHub is no small task," Uchitelle wrote in an earlier post. "It takes careful planning, good organization, and patience. The upgrade started out as kind of a hobby; engineers would work on it when they had free time. There was no dedicated team. As we made progress and gained traction it became not only something we hoped we could do, but a priority."

The team learned a lot from that Rails upgrade, Uchitelle said, and they used that knowledge on the Ruby upgrade, which was a bit more focused undertaking. They set up the application to be dual-bootable in both Ruby 2.6 and Ruby 2.7 by using an environment variable, she said. "This made it easy for us to make backwards compatible changes, merge those to the main branch, and avoid maintaining a long running branch for our upgrade," she said. "It also made it easier for other engineering teams who needed to make changes to get their system running with the new Ruby version."

GitHub was built with Ruby on Rails and launched in February 2008, and it's now one of the largest source code hosting service in the world, with an estimated 40 million users and more than 100 million repositories. The app itself is huge: more than 400,000 lines of code. And it gets 100s of pull requests daily.

One of the key goals of the upgrade was to make it possible to run both Ruby and Rails in deprecation-free mode and not be left behind in the future by a modern upgrade cadence, the code hoster has said. With this release, future versions of Ruby will no longer accept passing an options hash when a method expects keyword arguments. "At GitHub, we're committed to running deprecation-free on both Ruby and Rails to prevent falling behind on future upgrades," Uchitelle said.

Uchitelle left no doubt that the team feels the latest upgrade was worth all this effort, if for the performance improvements alone. " The Ruby Core team is well on their way to fulfilling the promise of Ruby 3.0 being 3x faster, she said. She also pointed to improvements in application boot times in production mode (down from about 90 seconds to about 70 seconds). She also cited a decrease in object allocations, which went from about 780k allocations to about 668k allocations. Object allocations affect available memory, she noted, so it's important to lower these numbers whenever possible.

"For any companies that are wondering if this upgrade is worth it, the answer is: 100%," she said. "Even without the performance improvements, falling behind on Ruby upgrades has drastic negative effects on the stability of your codebase. Upgrading Ruby supports your application health, improves performance, fixes language and framework bugs, and guides the future of the language!"

Both of Uchitelle's blog posts are well worth reading: "Upgrading GitHub to Ruby 2.7," and "Upgrading GitHub from Rails 3.2 to 5.2."

Posted by John K. Waters on September 1, 2020