Keynote: The Past, Present, and Future of Rails at GitHub

Talks

Eileen M. Uchitelle

#software-engineering

Keynote: The Past, Present, and Future of Rails at GitHub

by Eileen M. Uchitelle

In this closing keynote titled "The Past, Present, and Future of Rails at GitHub," Eileen M. Uchitelle, a staff engineer at GitHub, shares insights into the journey of upgrading Rails at the company and reflects on the implications of technical debt in application development. She begins by expressing gratitude to the conference organizers and humorously setting expectations for the talk, emphasizing the importance of communication.

The presentation covers the following key points:

History of Rails and GitHub's Fork: Eileen explains how GitHub started using Rails from day one, eventually forking it and creating a custom version due to performance concerns and feature differences, which led them to deviate significantly from the main Rails framework.
Consequences of Forking: Over the years, the decision to fork Rails created numerous challenges including slow upgrades, technical debt accumulation, and complicated hiring processes, as developers were hesitant to work on such an outdated version.
The Upgrade Journey: After years of stalling, a dedicated team was formed in 2014 to address the backlog of upgrades. Eileen details the systematic approach taken to upgrade from Rails 3.2 to 5.2, including lessons learned like dual booting the application to allow for gradual testing and integration of new versions without downtime.
Importance of Continuous Upgrading: Uchitelle highlights the necessity of keeping applications up-to-date to prevent the pitfalls of technical debt, emphasizing that failing to upgrade can lead to profound security vulnerabilities and diminishing capacity for onboarding new engineers.
Investment in the Future of Rails: Post-upgrade, GitHub engineers are now actively contributing to the Rails codebase, underlining their commitment to not just utilizing Rails but also shaping its future. Eileen stresses the importance of supporting the open-source community that underpins much of GitHub's success.

The talk concludes on a hopeful note, encouraging audience members to embrace the challenges of upgrading, noting that incremental progress toward eliminating technical debt will yield long-term benefits. Eileen reassures that with the right approach, organizations can elevate their frameworks and applications, thus enhancing overall efficiency and security.

00:00:06.000 For the last talk, we have Eileen here. Right now, she works as a staff engineer at GitHub. Before this, she worked in a photo studio where she made pictures by the thousands, which she didn't really enjoy. The work she does now is much more specialized, and I think it brings her a lot more joy. Let's give a round of applause for Eileen.

00:00:54.480 Hi everyone, can you hear me in the back? Good! Oh, there’s this countdown timer that’s really stressful because it started before I got up here. I first want to say thank you to the organizers for throwing a great conference and inviting me to be your final keynote. Hopefully, you won't be disappointed, and you enjoy the rest of the session. However, the only thing you will be disappointed by is that I don't have ship puns. If you want puns, go talk to Aaron; he does it all day long.

00:01:36.480 Alright, let's get started. As they said, I'm Eileen. You can find me online at the handle 'EileenCodes'—on Twitter, GitHub, my blog, or email—unless I don’t want you to find me. I'm a staff engineer at GitHub on our Ruby Architecture team, and we’re responsible for improving the Rails framework and the Ruby language so that it benefits GitHub. We add features, reduce technical debt in our applications, and ensure that the code our engineers write works with current and newer versions of Rails and Ruby. I'm also on the Rails core team. For anyone new to the Ruby ecosystem, the Rails core team decides the future of the framework. We are a group of about 12 people who review pull requests, merge them, and decide how the next version should look before doing the actual release.

00:03:14.400 Each year, I reflect on the work I’ve been doing and what I’ve learned, sharing insights at conferences where I speak. When I started writing the abstract for this talk, I thought I wanted to discuss the intimate details of upgrading Rails at GitHub. I spent over a year and a half working on upgrading GitHub from Rails 3.2 to 5.2, and I could talk about it for hours—maybe even days or weeks—until you were bored. But as I explored the themes around upgrading, I realized there was a deeper story I wanted to tell. I began to think about questions like how we ended up so far behind Rails master, what past decisions complicated upgrading, and what motivated us to upgrade when we were so far behind. This story focuses on the past, present, and future of Rails at GitHub.

00:05:10.160 We have been using Rails at GitHub since day one, and over the years, Rails and GitHub have had their differences. Many years ago, we forked Rails and practically wrote our own version. We deviated from the framework and wondered if Rails was right for us at all. However, at the end of the day, GitHub is successful because of Rails, and Rails is successful because of GitHub. Our upgrade was not just a good blog post for Hacker News to criticize; it enabled us to invest in Rails for the long haul. We can now influence the framework according to our needs while also benefiting the broader Rails community.

00:06:59.120 This story is partly historical as we look back at how GitHub ended up maintaining a custom fork of Rails 2, and it’s also technical as we explore what compelled us to upgrade and why it was so difficult. We'll examine the costs of not upgrading and how it causes technical debt to accumulate, potentially making your application and framework work against each other. Lastly, we will look forward, diving into GitHub's efforts to clean up technical debt, our commitment to open source, and our responsibility to support Rails for the long haul.

00:09:29.679 But first, let’s go back in time to the beginning. In 2004, DHH announced a new Ruby framework called Ruby on Rails. Immediately, Rails caught the attention of the Ruby community. At RubyConf that year, DHH talked about Rails' history, how it came to be, and why it is better than existing Ruby frameworks. He emphasized that many frameworks fail because they're built without an application in mind, stating that frameworks are retrospectives; they should be extracted, not built. Rails was attractive because it was extracted from a real application, Basecamp.

00:10:25.440 In the early years, Rails' complexity grew slowly, and Rails 1.0 was released in December 2005. Two years later, Rails 1.2 was released. That same year, Tom Preston-Werner was at a Ruby meetup in San Francisco when he showed his friend Chris Wanstrath a tool called Grit. Grit was a Ruby tool that allowed you to view Git repositories in an object-oriented way. This tool would become the basis for Git repositories on GitHub. After seeing Grit, Chris was immediately hooked. A few days later, the GitHub Rails application was born, created using Rails 1.2.3, and after a short beta, GitHub launched to the public in April 2008.

00:11:16.640 The next day, Rails moved their own SVN server to GitHub. In 2009, Rails 2.3 was released. In the early days, when Rails would release a new version, GitHub would quickly upgrade to get new features and bug fixes, and they were excited. However, sometime between 2008 and 2009, GitHub forked Rails. I couldn't find an exact date because we entered our gems, and there weren't any commits that made it clear exactly when we forked, but it was sometime between those two years. Personally, I had always thought that GitHub forked Rails because Rails 3.0 was known to be very slow, making it difficult for many applications to upgrade. But it turns out that we forked Rails long before that was ever a problem.

00:14:02.080 Now, remember, this was the wild west of Rails startups. No one really knew what the future of Rails or GitHub was going to be. We weren't yet talking about the importance of upgrades or staying current with Rails master. Honestly, Rails just wasn’t as stable as it is today. I won’t go so far as to say that Rails didn’t care about performance or stability at that time, but certainly, many developers felt that way. It wasn't a concern the way it is today. We work hard to ensure we're not breaking applications. We may have been inexperienced back then, or perhaps Rails was good enough for its most important user, Basecamp. Regardless, GitHub didn't contribute enough upstream. It’s important to understand what happened then so that we can avoid similar pitfalls in the future.

00:16:51.360 The problem was that GitHub didn't just fork Rails and add a bug fix here or a performance improvement there. It wasn't simply a fork with backports; GitHub's fork was Rails morphed into a different framework specifically built for GitHub. While Rails continued to progress rapidly, GitHub doubled down on their fork and added more functionality. No one at the time could predict the cost that forking Rails would have on the GitHub application or engineering team. In 2010, Rails 3.0 was released, but many applications couldn’t upgrade due to significant performance concerns. These performance issues in 3.0 were serious; users saw an unacceptable increase in response times, with some applications experiencing requests taking twice as long.

00:18:22.640 Active Record in Rails 3 was found to be five times slower than Rails 2. Despite knowing about these performance concerns, an engineer at GitHub started working on upgrading from Rails 2 to 3, as well as upgrading Ruby to 1.9. So, GitHub didn’t just fork Rails; we also forked Ruby, making upgrades particularly challenging. Fortunately, we no longer have that issue; it's gone. The Rails 3 upgrade wasn’t directed at Rails 3 upstream either; it remained a fork with GitHub's custom patches added on top. From my experience, I can tell you that maintaining a fork while trying to upgrade, and having to add all that stuff from your last fork on top of the new one, can make someone want to quit programming— and I don’t recommend it.

00:20:14.880 In 2012, Rails 3.2 was released, and most of the performance issues were addressed by Aaron Patterson and other contributors. However, GitHub's progress on the Rails upgrades stalled; it had been two years since the Rails 3.0 upgrade started, and the engineering team began questioning whether the effort was worth it. They pondered questions like: why upgrade when this version isn’t causing pain? Why upgrade to Rails 3.0 when the fork has more features? Looking at these questions, the engineering team concluded that upgrading wasn’t worth their effort and shifted their focus to other projects. The truth is that at that time, GitHub didn’t yet feel how painful being on a fork was. Convincing a team to upgrade without experiencing pain is challenging. You optimize tests when they’re too slow, and you refactor complexity when new functionality is needed, but the question remains: when do you upgrade? What’s the incentive if the new version isn’t significantly better and your fork is just fine?

00:24:11.840 Eventually, all these why-should-we-upgrade questions became suffocating for GitHub's engineering team. It became increasingly challenging to delineate where the framework ended and the application began as GitHub engineers struggled against the fork. Application security backports became a nightmare; each time Rails announced a vulnerability, GitHub was forced to patch it manually. Hiring became increasingly difficult as nobody wanted to work on a Rails 2.3 application that didn’t resemble typical Rails applications, making on-boarding engineers harder. Dependencies grew brittle and unsupported as gem authors focused on newer versions of Rails and abandoned the old ones. Development was slow and painful, and working with an application tied so heavily to a custom fork made adding features and refactoring code increasingly difficult.

00:26:47.440 We realized the necessity to upgrade. Our fork would suffocate the application if we didn’t make the change. In 2014, a team of four full-time engineers and a few volunteers came together, wrote an upgrade plan, and started the work. That team took six months of full-time coordinated effort to deploy Rails 3.0 to production, and a few months later, Rails 3.2 was deployed as well. It’s essential to remember that these versions still functioned as a fork with GitHub's custom patches. By that time, the Rails 3 series was only receiving severe security patches, so even though the upgrade was successful, the codebase remained far behind. The motivation dwindled thereafter. It would take another two years before we even started the Rails 4.0 upgrade, the same year Rails 5 was released. To some, it might have felt like GitHub would never catch up to Rails with its constant improvements and new releases.

00:30:02.560 In 2017, I joined GitHub, and at this point, the Rails 4.0 upgrade was not in a good place. There was no dedicated team working on it, and the upgrade had fallen by the wayside. It was something that people worked on when they had an extra hour or two, not something anyone devoted effort to. On my first day, I asked Hubot, our test-running bot, to tell me how bad Rails 4.0 was. When I asked Hubot to run the tests, there were over 4,000 errors—luckily for me, Hubot can't count; it was closer to 2,500 errors. Fortunately, after the Rails 3.0 upgrade, GitHub engineers had added some tooling that made future Rails upgrades easier. We developed a system that allowed us to boot the application in multiple Rails versions.

00:32:59.440 This means we didn’t need to maintain long-running branches and could work off master when ready. By adding dual booting, we focused solely on test failures instead of merge conflicts. Unfortunately, this method required us to hack Bundler because it didn't support multiple gemfiles, but I would rather monkey-patch Bundler than fork Rails. With this system, we could boot the server console and run tests in multiple Rails versions, enabling easy comparison of behaviors between the production version and the one we were upgrading to. This method allowed us to incrementally upgrade Rails over time and help prevent regressions. Once we had Rails 4.0 passing, we ensured everyone at GitHub wrote code that worked with both 3.2 and 4.0. When 4.1 was ready, we switched out the build to make sure that code worked with both 3.2 and 4.1, and we did this for every subsequent version until we had Rails 5.2 and Rails master in the application code.

00:34:39.680 By using helper methods, we could condition our code for the different Rails versions, always placing the production version in the if clause and future code in the else clause—ensuring we didn’t accidentally fall into the 3.2 branch. In March 2018, a year and three months after I started at GitHub, we deployed Rails 4.2 to production with zero downtime and no customer impact. After deploying 4.2, we immediately started the Rails 5 upgrade with a larger team. For the 5 series, I led a team of four full-time engineers and utilized GitHub’s projects and issues to streamline our work distribution. Because of our dedicated team and organized process, the upgrade from 4.2 to 5.2 took only five months. In August 2018, we deployed Rails 5.2 to production, also with zero downtime and no customer impact. After learning from our 4.2 deployment, we were much less anxious about rolling out 5.2.

00:37:18.080 I think the 4.2 deployment took us three to four months to finalize, while 5.2 was done in about one month. Sometimes you might hear me complain about our test suite, but it actually wasn’t that bad for upgrades. This upgrade represented a significant milestone; it was the first time in 10 years that GitHub was not on a fork of Rails and had the most recent version. That meant 10 years of cumulative technical debt and 10 years of fighting against our fork, crushing us under the weight of it. By upgrading, we started to pay off that debt. While we do not eliminate technical debt, it creates breathing room in your application that we just didn’t enjoy for a decade. I hope learning about our upgrade process doesn’t scare you out of pursuing your own. The point of this talk is not to share horror stories but to show you that the cost of not upgrading is cumulative.

00:39:00.960 After sharing the Rails upgrade story at GitHub, I've had engineers come to me seeking advice on how to convince their leadership teams to prioritize upgrades. Many times, they lack resources or the task isn’t in their roadmap or won’t fit in the company’s budget. It’s true that upgrading is expensive and time-consuming; I won’t lie about that. However, it’s easier to convey these costs by saying that this upgrade will require a specific number of engineers at a certain cost for a designated timeframe. You can actually calculate and measure that cost to decide whether or not it's too expensive. However, at the end of the day, it doesn’t matter how costly upgrading will be because the cost of not upgrading is immeasurable.

00:41:04.960 Not upgrading your application will eventually cost more than any upgrade because of the debt that accumulates in that duration. With Rails, you must become a security expert. The Rails core team only supports patching security vulnerabilities in the major current version and in the major versions of the preceding version; therefore, as soon as we release Rails 6, 4.2 is no longer supported. I know a lot of you in this room are still using 4.2. If you are, your team will be responsible for identifying and patching vulnerabilities yourself. It’s challenging to get this right because on the Rails security team, we don't reveal how to exploit the vulnerability—at least, we try not to. Not upgrading forces you to become a security expert and obliges you to patch problems manually.

00:43:24.080 Additionally, when you upgrade Rails, you miss out on great talent such as boot camp grads, college grads, and career changers. New engineers aren’t learning Rails 2.3, and they're definitely not familiar with your unique custom fork. Those engineers not only don’t want to work on an obsolete version; they often lack the requisite skills or knowledge to contribute effectively. Engineers may decline to work for you if you’re on an old version because it hinders their ability to contribute to open source; older versions are less searchable and are widely considered outdated. If you don’t upgrade, some of the gems you rely on will get deprecated, forcing you to either manage with bugs or fork yet another dependency. New gems may not support old versions of Rails if you remain on unsupported versions, complicating development further.

00:45:03.920 Every choice within dependencies becomes increasingly difficult as you fall behind. Maintaining obsolete gems on top of your outdated framework quickly becomes tedious. When you don’t upgrade Rails, you inevitably build more infrastructure on a fragile application. I’ve seen this firsthand at GitHub; we have extensive infrastructure code within our app, including multiple databases and CI tooling, along with our job queue. Ideally, your application would consist only of code that delivers value to your product. GitHub's value lies not in having multiple databases; that is simply necessary for keeping our application running. Such infrastructure code complicates development due to its close ties to Rails internals. Minor changes can lead to significant refactoring or abandoned projects.

00:47:56.960 The largest consequence of not upgrading Rails is that one day someone will decide using Rails was a mistake, prompting a shift towards carving your application into microservices. Now, this isn’t a competition of programming languages; I’m not here to criticize Go or how companies build their infrastructures. But if you already possess a monolith, it's best to respect it. Also, since we are at a Ruby conference, I will assume you all at least enjoy writing Ruby. This may sound like an exaggeration, but if we don’t upgrade Rails, we might lose the privilege of writing Ruby altogether. The Ruby ecosystem will stagnate, our applications will degrade, and we will face potentially costly rewrites. As Matt said yesterday, 'If Ruby dies, his family dies.' Therefore, by transitive property, failure to upgrade Rails will doom Matt's family.

00:50:20.120 That is a heavy notion! The key to upgrading Rails is to incrementally address technical debt while developing a sustainable plan to keep that debt in check. I am not going to pretend that upgrading Rails will be an easy process; I’ll leave that to the person on Hacker News who wondered why I couldn’t do it all in a weekend. The upgrade certainly took a long time, but it wasn’t the sole focus of our efforts. I took the time to eliminate unused features, revamp our custom test framework, and improve database handling for development and test environments. It's unjust for anyone to scrutinize our upgrade timeline and conclude that using Rails is overly expensive. At GitHub, we made choices that complicated our upgrade process, and so will you. This doesn’t mean that Rails is a poor choice—technical debt is real and can manifest in any programming language.

00:52:59.520 At GitHub, we’ve decided that being behind Rails master is no longer acceptable technical debt. You can gradually work on technical debt and upgrade Rails to get your application into a better state. There are several key considerations when upgrading and mistakes to sidestep, so your upgrade doesn’t span two to seven years like ours did. The first and most crucial step is to build out a team. Upgrades are inherently challenging, and it helps to have a team for support, brainstorming, and maintaining momentum. If you establish a one-person upgrade team and that individual leaves the company, your upgrade could stutter or even halt altogether.

00:54:06.400 Ensure redundancy in the event of a challenging task. If your team is too diminutive to pause feature development for an upgrade, consider hiring a contracting firm to assist in getting out of the weeds. Though it may be costly, it’s still cheaper than perpetually postponing the upgrade. This can also facilitate the implementation of best practices, keeping you from falling too far behind in the future. Another aspect that simplifies upgrades is planning. Your team should discuss whether to upgrade incrementally from 3.2 to 4.0 to 4.1, or to leap straight from 3.2 to 5.2. Numerous reasons exist for either option, so those considerations are crucial.

00:56:03.040 You can simplify your upgrades by addressing deprecation warnings early rather than ignoring them. Fixing issues proactively is important to ensure your app remains functional. For instance, alias method chain deprecations will prevent your app from booting until they’re resolved; addressing them allows for parallel work and expedites your overall upgrading process. After upgrading to the most recent version, make a plan for the future: how frequently will your team upgrade Rails going forward? Are you willing to test new releases during the beta or release candidate phase? Collaborating with the Rails team about pain points can help make future upgrades smoother. Additionally, if you can't run Rails master in production, consider investing in dual boot CI so that you can concurrently test version 5.2 and 6.

00:58:51.120 If you invest in the upgrading process, it makes sense to invest in future tooling to prevent falling into upgrade debt again. Now that we’ve considered what to keep in mind while upgrading, let’s discuss what to avoid and likely regret. A major choice that can complicate upgrades is forking Rails. The decision to fork Rails was the single most costly choice we made concerning our application at GitHub. This choice had an ongoing, compounding impact on the state of our codebase, making upgrades take far longer than they should have. If you decide to fork Rails, attempt to track the upstream version closely and backport only the bug fixes or features required. Avoid adding features that you don't intend to upstream into your fork, as that will cause your fork to diverge from Rails and complicate future upgrades.

01:01:26.720 Another regrettable choice is allowing your Rails upgrades to stall until the Rails team no longer supports your version. If you must stick with an outdated, unsupported version, use Rails long-term support (LTS)—they’ll maintain the fork for you and reduce the burden. Falling behind on upgrades means you’ll have to write your own patches, increasing the risk of doing it wrong and leaving your application vulnerable. In general, it’s best to apply security patches via the Rails upstream; that’s the safest approach to confirm that your application remains secure and stable. If you are using outdated unsupported gems, upgrading Rails will only become more difficult as you’ll need to replace those dependencies before completing your upgrade. It’s quite challenging to replace dependencies while simultaneously upgrading Rails. Therefore, ensure that you frequently upgrade dependencies to align with Rails requirements to avoid relying on deprecated gems.

01:03:46.320 The decisions you make can compound upgrading costs. It's vital to see how these choices will accumulate debt in your applications. I hope that by now you're a bit more confident that you too can upgrade Rails. I know it will be difficult; you may cry, feel angry, or curse past engineers who worked at your company. I, for one, did, and I apologize to everyone I cursed! I want you to know you can do it. I have faith in you. You might be thinking, 'Okay, Eileen, maybe it wasn't easy; you're on the Rails core team and work at GitHub. I don't possess the skills to execute an upgrade; it seems overwhelming.' But here’s something that surprises a lot of people: before the Rails 3.2 to 5.2 upgrade, I had never completed a significant multi-version Rails upgrade in my career.

01:05:33.920 If I can do this, so can you! I’m not inherently smarter or better; maybe I’m just more stubborn. Keep in mind that dealing with these cumulative costs we've discussed earlier is essential while working on your upgrade. It's crucial to recognize that you don’t need to resolve all your technical debt issues overnight. You can incrementally address debt, starting with a class that utilizes a private Rails API, removing or documenting your monkey patches, and prioritizing upgrades for outdated Rails dependencies. Upgrading Rails isn't a sprint; it’s a marathon, and it might feel never-ending.

01:07:02.080 However, if you gradually pay down the debt you incur over time, you will ultimately achieve a much healthier application state. Additionally, remember that you're not alone—many have upgraded before you, and many will do so after you. Seek out others at the same point in their upgrade journeys or those who have completed upgrades in the past and lean on them for support. Lastly, remember that the payoff is well worth the effort. Upgrades are challenging and time-consuming, but letting fear dictate your choices won’t resolve the situation. When your application finally gets upgraded, it will be in a much better place, offering not only better security, easier hiring, and more manageable dependencies—but the hard work will yield improved APIs.

01:08:57.920 Upgrading to new Rails versions allows the Rails team to consider future API improvements. For example, Rails 6 introduced enhanced handling for multiple databases. Previously, adding multiple databases to an application was cumbersome; you had to code everything yourself. However, Rails 6 introduced new APIs for establishing and managing connections, as well as improved Active Record database configurations. Without upgrading, you would miss these enhancements. Furthermore, upgrading significantly boosts security. Newer Rails versions include new security features to protect your application from users and bad actors. For instance, Rails 5 introduced built-in CSRF tokens, and Rails 5.2 added encrypted secrets while Rails 6 will enhance security around potentially dangerous methods.

01:10:36.640 Upgrading not only keeps your applications safe but also grants you access to new features in libraries. Rails 6 is bundled with exciting new libraries such as Action Text, Action Mailbox, and our new auto-loading framework called Zeitwerk. Thus, upgrading allows you to utilize these advancements rather than having to develop your own infrastructure tooling. Ideally, your application would solely comprise code directly associated with its functional value. If your product does not revolve around sending mail, then do not clutter your application with any mail-sending code. Upgrading Rails preserves the distinction between where Rails ends and your application commences.

01:12:46.320 Lastly, upgrading your application gives you the opportunity to contribute upstream. Addressing bugs, adding features, and influencing the future of Rails is much more feasible from newer versions. It is not a requirement to contribute if you are on the latest version and prefer not to, but it certainly opens the door for greater influence. As DHH stated in 2004 and many times since: frameworks are extracted; we build Rails based on existing needs. If those needs are stuck in Rails 2.3, making a case for necessary extractions is complicated. All the aforementioned points make compelling reasons to upgrade, but the most pivotal charge that kept me motivated through the year and a half of upgrading Rails at GitHub was the ability to influence Rails' future.

01:14:36.320 For GitHub, this is the most crucial reason to upgrade. By upstreaming features, fixing bugs, and supporting Rails' future, we also secure our own future. Reflecting on the beginning of the 3.2 to 5.2 upgrade, the thought of being on a current version of Rails and actively contributing felt like an unattainable dream, given how far behind we were. Despite my doubts, I often questioned whether we could actually finish—at least without losing most of my sanity; that part remains debatable. Now, contributing regularly to Rails and supporting the framework's future is GitHub's present and future state.

01:16:58.080 Since upgrading Rails, GitHub engineers have submitted over 75 pull requests to Rails 6, improving performance, fixing bugs, and adding major features. Before the upgrade, we were often compelled to resort to monkey patches or complex workarounds to address bugs. Yes, even with our custom fork, we still had numerous patches. I don’t understand how that worked! Utilizing Rails 5.2 enabled us to not only contribute upstream but also make choices that enhance our application rather than hinder its performance. All of you stand to benefit from those changes, adding to the bug fixes and performance improvements extracted from GitHub. I will not delve into technical specifics, but we have managed to extract our handling of multiple databases into Rails 6, leveraging our knowledge and expertise in database management to create a robust new API for defining, establishing, and switching data connections.

01:19:35.920 This extraction benefits not only Rails but helps reduce complexity within our application. We have made a commitment to never fall behind again; at GitHub, we are investing in our application and Rails through continuous upgrades. We bump Rails every week and run all of GitHub's tests against the new versions, ensuring that Rails 5.2 is stable. Having completed the challenging work of upgrading major versions, this new process ensures we will never fall behind again; upgrades will occur as Rails evolves instead of being postponed for years. Because of this commitment, we are confident that Rails 6 is stable, performant, and resilient.

01:21:19.040 Continuous upgrades and contributions to Rails serve as proof that, for the first time in GitHub’s history, we’re not merely utilizing Rails or constructing a Rails application. We are pioneering the future of Rails. We are extracting code from GitHub, building new features into Rails that help scale your applications, and giving back to the open-source community to support Rails for the long term. It is wise for us to do this; not only do we give back to the community, but it keeps our application aligned with our product while lowering complexity and enhancing resilience.

01:23:00.080 At GitHub, we not only need to do this for our application’s sake but also for our responsibility to support Rails. We owe part of our success to the Rails framework, and we have the influence, expertise, and application to help advance Rails. Upgrading Rails was a massive investment; it wasn’t cheap, but it was incredibly worthwhile as it opened up a myriad of possibilities for our future. We’re building features more efficiently, and we have greater confidence that our codebase is stable.

01:24:34.960 We’re improving the scalability of Rails while giving back to the open-source community. At a minimum, we transitioned from being overwhelmed by our application and Rails—along with the decisions we made—to building our application, contributing to Rails, and enhancing our community. Upgrading afforded us the freedom and flexibility we previously lacked, empowering our engineers to create more and better solutions. In 2007, GitHub was born, and 11 years later, we are finally tracking Rails master. It took seven years from initiating the Rails 3.0 upgrade to completing the Rails 5.2 upgrade. I find the future bright ahead, and I can’t wait for you to witness what the next decade will hold in terms of our ability to extract from GitHub and Rails and how the Rails community will thrive. At GitHub, we will continue to invest in the future of Rails and in our community because we must, because we want to, and because GitHub and Rails are in this together for the long haul.

01:36:11.840 Thank you.

01:37:51.840 Thank you so much, Eileen. That was wonderful! It’s funny that you mention a major upgrade because Arnold and I just got upgraded to majors. A little treasure from us. Thank you!

EuRuKo 2019