The Past, Present, and Future of Rails at GitHub

00:00:20.869 Hi everyone! Thanks for coming to my talk. I know that the after-lunch slot can be a little exhausting, but I promise that this will be fun and interesting.

00:00:28.320 I'm Eileen, and you can find me anywhere online at the handle EileenCodes, so that's on Twitter, GitHub, and I even have a blog, although I haven't written in it for two years.

00:00:33.809 But it exists, and if I ever do write something, it'll be on there. I'm a staff engineer at GitHub, where I work on the application architecture Ruby language team.

00:00:41.220 We focus on setting standards, figuring out how to build things in Rails and Ruby, and we do a lot of work to improve the languages and frameworks that we use. We contribute a lot of tooling to Rails and improve Ruby's performance, so you all benefit from our work.

00:00:57.270 I'm also a member of the Rails core team. For those of you who are new to Rails and haven't heard of the core team, it's a group of engineers who work on the Rails framework. Many of us are volunteers, and while some of us are paid by our jobs to work on it, for the most part, we do this because we love Rails.

00:01:12.570 The core team is responsible for determining the future of the framework, what features will be included in upcoming releases, and when those releases will happen. Each year, I reflect on what I've learned during the past year and what I would like to share with you all at conferences. This year, when I started drafting the abstract for this talk, I originally thought about discussing the intimate details of upgrading Rails at GitHub.

00:01:37.679 I spent a year and a half upgrading GitHub from Rails 3 to 5, and I could definitely talk about that for many hours—maybe even days—until you were all bored. However, as I started to explore the themes around upgrading, I realized there was a deeper story I wanted to tell.

00:02:01.349 I began pondering some important questions: How did we end up so far behind Rails master in the first place? What past decisions made our upgrade more difficult? What motivated us to upgrade, given how far behind we were? And what does the future look like now that we're on Rails master?

00:02:23.700 The story I want to share with you is about the past, present, and future of Rails at GitHub. We've been using Rails at GitHub since day one, and at times, Rails and GitHub have had our differences. Many years ago, we forked Rails and essentially wrote our own version.

00:02:50.370 We fought against the framework, deviated from it, and even questioned if Rails was right for us at all. However, at the end of the day, Rails is successful because of GitHub, and GitHub is successful because of Rails.

00:03:08.280 Our upgrade didn't just provide a good blog post for Hacker News to criticize; it enabled us to use and invest in Rails for the long haul. We can change and influence the framework to fit our needs while also benefiting the broader Rails community and the open-source ecosystem.

00:03:33.980 This narrative is part historical, as we will reflect on how GitHub maintained a custom fork of Rails 2, and part technical, as we explore our reasons for upgrading and the difficulties we faced.

00:03:39.870 We'll examine the costs of not upgrading and how technical debt accumulates in an application until your framework and application begin to conflict.

00:03:58.440 Finally, this story is forward-looking. We'll dive into our efforts at GitHub to clean up technical debt, our commitment to open-source, and our responsibility to support Rails for the long haul.

00:04:11.549 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.

00:04:23.639 At RubyConf that year, DHH talked about Rails, its history, how it came to be, and, of course, why it was better than existing Ruby frameworks. He also discussed his philosophy behind building the framework: that many frameworks fail because they are built without a specific application in mind.

00:04:42.479 He asserted that frameworks should be extracted, not built, and Rails was successful because it was extracted from a real application—Basecamp. In the early years, Rails' complexity grew slowly; Rails 1.0 was released in December 2005.

00:04:53.759 Two years later, Rails 1.2 was released. That same year, Tom Preston-Warner attended a Ruby meetup in San Francisco, where he introduced his friend Chris Wanstrath to a tool called Grit.

00:05:10.470 Grit is a Ruby tool that allows you to view Git repositories in an object-oriented way. It would become the foundation for Git repositories at GitHub. After seeing Grit, Chris was hooked, and a few days later, GitHub was born.

00:05:24.199 GitHub was created using Rails version 1.2.3, and following a brief beta phase, it was launched to the public in April 2008. The next day, Rails transitioned from their own SVN server to GitHub.

00:05:39.599 In 2009, Rails 2.3 was released, and in the early days, when Rails would release a new version, GitHub would upgrade quickly to take advantage of the new features and bug fixes. However, between 2008 and 2009, GitHub forked Rails.

00:05:52.289 While I couldn't find an exact date for when this happened (since we vendor our gems at GitHub and there wasn't a single commit that clearly indicated this fork), it definitely occurred sometime during those years.

00:06:07.080 I had always thought the reason GitHub forked Rails was due to Rails 3.0's poor performance, which many applications struggled with as a result. However, it turns out that GitHub was already venturing into the realm of Rails before we even identified Rails 3.0 as a problem.

00:06:17.370 Remember, this was the Wild West of Rails start-ups. No one really knew what the future of Rails or GitHub would be. At that time, discussions about the significance of upgrades, or the importance of staying current on Rails master, just weren't taking place.

00:06:36.300 Rails was not as stable then as it is today. I don't mean to say that Rails didn't care about performance or stability, but many developers felt that way, and stability wasn't as much of a concern for us at the time.

00:06:49.889 It might have been due to our inexperience back then, or perhaps Rails was satisfactory for its major user, Basecamp. And maybe it was because GitHub didn't contribute enough upstream.

00:07:02.110 Regardless, we need to reflect on what we did wrong in the past to improve our future. The problem was that GitHub didn't just fork Rails and make a bug fix here and a performance improvement there.

00:07:20.650 It wasn’t a traditional fork with backports from upstream—GitHub's fork was Rails with custom code specifically designed for GitHub. It effectively morphed into a different framework created for our unique needs.

00:07:34.520 It was akin to how Rails was built for Basecamp. As GitHub doubled down on our fork and added more functionality, Rails continued to advance at a rapid pace.

00:07:50.560 No one could accurately predict or comprehend the costs associated with working on Rails while at GitHub. In 2010, Rails 3.0 was released, but many applications couldn't upgrade due to performance concerns.

00:08:02.320 The performance issues in Rails 3 were significant—users experienced unacceptable increases in response times, with some applications seeing requests taking twice as long. Active Record in Rails 3 was found to be up to five times slower than in Rails 2.

00:08:17.640 Despite these performance concerns, GitHub engineer Amin Gupta, also known as tm-1, began working on upgrading GitHub from Rails 2.3 to Rails 3 and Ruby 1.9.

00:08:28.210 However, GitHub hadn't only forked Rails; we had also forked Ruby 2, which made upgrades significantly more complicated. Additionally, the Rails 3 upgrade wasn’t focused on Rails 3's master upstream—it was still based on our custom fork with patches from GitHub.

00:08:43.520 I can tell you from experience that maintaining a fork while simultaneously trying to add features on top of it is enough to make anyone want to quit programming and become a goat farmer.

00:08:56.110 In 2012, when Rails 3.2 was released, most performance concerns had been addressed by Aaron Patterson and other contributors. However, after addressing these issues, GitHub's progress on the Rails upgrade stalled.

00:09:06.740 It had been two years since the Rails 3.0 upgrade effort began, and the engineering team began questioning whether the effort was even worth it. They asked each other: Why upgrade when the current version isn't painful? Why upgrade when Rails 3.0 isn't particularly impressive?

00:09:21.310 And why upgrade when our fork has more features? Looking at these questions, the engineering team decided that the upgrade wasn't worth their time and chose to focus on other projects.

00:09:37.000 The truth is that, at that time, GitHub wasn’t feeling the pain of our fork. How do you persuade an engineering team to upgrade when they feel productive? You do it by making your tests faster when they feel too slow. You refactor a complex class when you need to add new functionality.

00:09:56.090 But when do you upgrade? What’s the incentive if the new version isn’t better but is working perfectly well?

00:10:04.150 If you're not feeling the pain of running an old version, you're not compelled to upgrade. Ultimately, all of these 'Why upgrade?' questions would become suffocating for the engineering team. It became increasingly difficult to identify where the framework ended and the application began.

00:10:20.300 As GitHub engineers battled against the fork, application security backports were a nightmare. Each time Rails announced a new vulnerability, GitHub was forced to manually patch it. Hiring became increasingly challenging; nobody wanted to work on a Rails 3-2-3 application that didn’t even resemble Rails.

00:10:39.650 It was harder to onboard new engineers, and Google searches yielded limited results. Dependencies were brittle and unsupported as gem authors focused on developing new versions of Rails.

00:10:56.050 Development was slow and painful, especially when your application is so heavily tied to a custom fork. Eventually, we recognized that we needed to upgrade. The fork was suffocating the application.

00:11:13.349 In 2014, a team of four full-time engineers, along with some volunteers, came together to outline an upgrade plan and began working on it. The team dedicated six months of full-time effort to upgrade to Rails 3.0 and deploy to production.

00:11:26.120 A few months later, they deployed Rails 3.2 to production as well. It’s crucial to note here that both 3.0 and 3.2 were still forks with GitHub's custom patches.

00:11:39.509 By this time, the Rails 3 series was only receiving critical security patches, so even though the upgrade effort was a success, the codebase and our fork were still significantly behind.

00:11:54.410 The effort needed to upgrade from 2.3 to 3.2 was massive, and unfortunately, motivation dwindled afterwards. It would take another two years before the Rails 4.0 upgrade effort commenced. That same year, Rails 5.0 was released.

00:12:02.750 I'm sure it felt to some that GitHub would never catch up, given that Rails was constantly improving and releasing new versions. In 2017, I joined GitHub.

00:12:15.180 By this time, the Rails 4.0 upgrade was in a poor state, lacking a dedicated team that was actively working on it. The decision to upgrade had fallen by the wayside.

00:12:31.000 So, on my first day, I asked Hugh, 'Can you run the Rails 4 tests? I want to see how bad it is.' We ran the tests, and HughBot reported over 4,000 errors.

00:12:49.199 Luckily, HughBot can't count; it was more like 2,000 errors. So, that seemed manageable, right? After the 3.0 upgrade, GitHub engineers introduced tooling that made Rails upgrades easier.

00:13:00.338 We set up a system that allowed us to dual-boot the application across multiple Rails versions. If you've seen Shopify's talks on this, we used a similar, albeit different, system.

00:13:11.949 This setup eliminated the need to maintain long-running branches. By allowing us to dual-boot the application, we could focus solely on test failures instead of working through merge conflicts.

00:13:25.820 Unfortunately, this method required some hacking; however, I would prefer to hack Bundler than maintain a fork of Rails. This approach enabled us to boot the server or console and run all of the tests across multiple Rails versions, facilitating comparisons between the production version and the version we were upgrading to.

00:13:35.200 It also allowed us to incrementally upgrade Rails while preventing regressions. Whenever we had a build that passed, we made it mandatory for everyone to write code in both the new and the old versions.

00:13:49.990 As a result, when the old build was green, we would swap it out for the new one, and the team would work on that. We also implemented helper methods to conditionally handle different Rails versions.

00:14:07.680 We would always place the production version in the 'if' clause and feature codes in the 'else' clause. When upgrading to 4.0, the same tests that we had previously fixed wouldn’t fail in the 3.x branch.

00:14:18.000 In March 2018, just three months after I joined GitHub, we deployed Rails 4.0 to production with zero downtime and minimal customer impact. After deploying 4.0, I wanted to start on the 5.0 upgrade immediately, as I didn't want us to lose momentum.

00:14:32.000 However, I had been the only engineer working full-time on the Rails upgrade, and while I had several engineers helping, they volunteered their time. I couldn't force them to participate in the upgrade.

00:14:58.030 Upgrading Rails was challenging and a lonely endeavor, and I decided I wouldn’t tackle the 5.x series alone.

00:15:14.640 For the Rails 5 upgrade, we formed a dedicated team of four full-time engineers. By that time, I had learned what processes worked and which didn't.

00:15:26.400 I utilized GitHub projects and a CI tool to create unique issues for every single failure, which allowed us to track our progress and avoid duplicated work.

00:15:40.720 This approach also meant that any volunteers could easily pick an issue, address it, and move on without needing to ask me for guidance on what to focus on.

00:15:56.140 With a dedicated team and a streamlined process, the upgrade from 4.0 to 5.0 took only five months. In August 2018, we deployed 5.0 to production with zero downtime and no customer impact.

00:16:06.980 We learned a lot from the 4.x deployment, and we were much less anxious about deploying 5.0 than we had been about 4.0. It took us a few months to deploy 4.0 because it was a new experience for us, and we were uncertain about what we should be cautious about.

00:16:22.320 However, after that, we pushed 5.0 out without hesitation. This was a significant milestone—it marked the first time in ten years that GitHub wasn't using a fork of Rails.

00:16:37.770 This was the first instance where GitHub was on the most recent version of Rails, which also represented ten years of accumulated technical debt and years of battling with our fork.

00:16:50.430 We had finally started to address that debt through upgrading. While we didn’t eliminate technical debt entirely, we created breathing room that the application had lacked for a decade.

00:17:04.640 I hope sharing our upgrade story hasn't deterred you from pursuing your own upgrades. The goal of this talk isn’t to recount horror stories; it's to illustrate that there are costs associated with not upgrading, and those costs accumulate over time.

00:17:16.820 After discussing the Rails upgrade at GitHub, I’ve had many engineers approach me seeking strategies for convincing their leadership teams to prioritize upgrades alongside feature development.

00:17:33.400 They often lack the resources, or feel it's not prioritized in their roadmaps, or they believe it might be too expensive. I acknowledge that while upgrading can be costly and time-consuming, it is crucial.

00:17:46.200 It's easy to say, 'This upgrade will require X number of engineers at Y rate for Z hours,' which is measurable and can lead to cost assessments. But ultimately, the financial implications of upgrading pale in comparison to the immeasurable costs that stem from not upgrading.

00:18:06.120 Not upgrading your application will inevitably cost you more money in the long run, as the technical debt continues to build. When you decide to refrain from upgrading Rails, you essentially become a security expert.

00:18:20.000 The Rails core team only provides patch support for security vulnerabilities in the current major version and the previous major version. For instance, we currently support Rails 5.2, 5.1, and 5.0, but once Rails 6.0 is released, support for 5.0 will cease.

00:18:33.570 I know many of you in this room are using Rails 4.2, as I've met many developers working with that version. If your team continues using that version, you'll be responsible for identifying and patching security vulnerabilities.

00:18:48.320 This is difficult to manage since the Rails team won't disclose how vulnerabilities can be exploited to safeguard users of Rails who haven’t upgraded yet.

00:19:04.230 Additionally, when you forego upgrading Rails, you're likely to miss out on great talent. Bootcamp graduates, college graduates, and many new engineers entering the Rails space haven’t learned Rails 2/3.

00:19:19.780 Those engineers aren't just hesitant to work on an outdated version; they may lack the knowledge to comprehend how your system functions.

00:19:35.500 Engineers might decline an opportunity at your company if they're aware you're operating on an old version because it limits their ability to contribute upstream. An outdated framework is no longer searchable, and there’s a significant gap in modern development.

00:19:50.480 When you choose not to upgrade, some of the gems you depend on may become abandoned or deprecated, meaning you'll either have to live with bugs or fork yet another dependency.

00:20:06.540 To be clear, the answer to this issue isn’t just to create your own gems—many new libraries may not support older versions of Rails, which further hampers your progress.

00:20:25.390 This situation complicates development because the deeper you are behind, the more arduous every dependency choice becomes. Maintaining older gems alongside an outdated framework quickly becomes a tedious task.

00:20:39.550 As you avoid upgrading Rails, you'll continually build more infrastructure on top of a fragile application. I've seen this first-hand at GitHub, where we have numerous infrastructure components: multiple databases, CI tooling, job queues, and probably more that I’ve yet to identify.

00:20:55.240 Ideally, your application should consist solely of the code that constitutes your product. GitHub's value lies in our community, issues, and repositories. Our multiple databases enable us to keep our application operational, but they aren't the reason customers choose us.

00:21:10.450 This infrastructure can complicate development by tightly coupling our application to Rails internals, leading to minor adjustments often resulting in major refactorings or abandoned projects.

00:21:27.010 The most significant cost of not upgrading Rails is that one day, someone at your company might declare that using Rails is a mistake, and it will become necessary to decompose the application into microservices.

00:21:40.870 I’m not promoting a language war; I’m not criticizing Go or any other language. If you want to write in Go, that’s entirely fine. However, we are at RailsConf, so I'm assuming you enjoy writing Rails.

00:21:57.320 I love writing Rails and want to continue being compensated for it. It may seem hyperbolic, but if we don’t upgrade Rails, we may not have the opportunity to keep writing it.

00:22:14.340 The Rails ecosystem won’t improve, our applications will degrade, and we'll be left with a costly rewrite ahead of us. If you think upgrades are expensive, rewriting will come with a hefty price tag and might even cost you your job.

00:22:30.430 Updating Rails is fundamentally about incrementally addressing the cumulative technical debt you've incurred and then devising a plan to keep that debt manageable.

00:22:48.550 I’m not here to convey that upgrading Rails will be easy. I'll leave that to the commenters on Hacker News who wonder why I didn’t complete the upgrade faster because theirs took a weekend.

00:23:03.730 The upgrade process did take time, but it wasn’t the sole focus of our work during that period. I took time to eliminate features, rewrite our custom test framework, and enhance our handling of databases, both in tests and development.

00:23:17.440 It’s unjust for anyone to scrutinize our upgrade timeline and conclude that using Rails is too costly. Decisions at GitHub made upgrading more difficult, and you're likely making similar choices in your applications that will complicate your own upgrade processes.

00:23:32.400 Technical debt is real, and you and your team must determine what kind of technical debt is acceptable and what requires remediation. At GitHub, we have come to terms with the fact that being behind Rails master is now a form of technical debt we are unwilling to endure.

00:23:52.540 You can gradually work on technical debt while upgrading Rails, thus improving the overall state of your application. Several considerations should guide you during the upgrade process, as well as common mistakes you'd want to avoid to prevent dragging out an upgrade process for many years.

00:24:10.750 The first and perhaps most crucial step is to establish a team. Upgrades are exceedingly challenging, and having a supportive team to bounce ideas off of is incredibly beneficial.

00:24:32.530 If you have a one-person upgrade team and that individual leaves the company, the upgrade is likely to grind to a halt or be significantly stalled. Ensure you create redundancy and support for such a difficult and isolating task.

00:24:52.020 If you are part of a small team that urgently needs to upgrade, consider contracting work out to a firm like Testable to help alleviate some of the burden. It may be a pricey undertaking, but it will be more cost-effective than not upgrading.

00:25:10.880 They can also assist you in implementing best practices to prevent falling so far behind Rails master in the future. Upgrading Rails becomes simpler when you take the time to plan the process.

00:25:30.360 Your team should gauge whether you prefer a gradual upgrade from 3.x to 4.0 to 5.0, or if you'd rather 'rip the band-aid off' and jump straight to 5.x.

00:25:46.350 Incremental upgrades can be beneficial because they allow you to observe deprecation warnings. Alternatively, if your tests are robust, you might decide that performing an upgrade in one go makes sense.

00:26:07.020 At GitHub, we acknowledged that the upgrade would stretch long enough to justify working incrementally, ensuring we could remain motivated throughout. Had we attempted to jump straight to Rails 5 in one fell swoop, it would have likely taken more than a year and made convincing leadership to continue difficult.

00:26:24.570 It’s always encouraging to show small wins repeatedly to prove progress. Furthermore, you might want to consider implementing dual-booting CI or branch systems to assist with reducing future debt.

00:26:42.330 The dual-booting CI can significantly help you pay down your debt, making future upgrades smoother. Running long-lived branches can become quite challenging when trying to align with new features being added to master.

00:27:01.500 You should also make your upgrades easier by resolving deprecation warnings early instead of procrastinating until the next version. If you encounter deprecation warnings, they’re typically related to significant changes and can block your upgrade until addressed.

00:27:20.030 For those of you who have dealt with the alias method chain deprecation warning, you know that your application might not boot if that deprecation warning is present.

00:27:37.660 You want to address that proactively rather than wait until it becomes an obstacle in your upgrade process. Fixing them early enables you to understand all the failures and gauge how far behind you really are.

00:27:51.560 Once you've successfully upgraded to the latest version, devise a plan for future upgrades. Consider how frequently your team is willing to upgrade Rails moving forward.

00:28:04.450 Are you interested in testing new releases of Rails in the beta or release candidate phases? This can help facilitate smoother upgrades for everyone since you can provide real-time feedback to the Rails team.

00:28:19.170 If running Rails master's latest version in production isn't feasible yet, can you at least invest in dual-booting CI? This setup can allow you to simultaneously test against Rails 5 and 6.

00:28:37.300 If you’re committed to upgrading, it’s wise to invest in tooling for the future so that you can avoid upgrade debt. Now that we have examined considerations for upgrading, let's assess decisions you may later regret.

00:28:54.680 Many choices in your application can make upgrading or maintaining it exponentially harder. One significant choice you might come to regret is forking Rails; don't do this.

00:29:09.930 Forking Rails and deviating from upstream was the most costly decision we made at GitHub with respect to our application. This had a compounding effect on the state of our codebase, leading to the arduous seven-year upgrade journey from 2.x to 5.x.

00:29:29.680 If you absolutely must fork Rails, try to track the upstream version closely and only apply bug fixes or features that are essential. If you add features you never intend to submit upstream, your fork will diverge significantly, complicating future upgrades.

00:29:44.210 You may also regret falling behind on security upgrades to the point where Rails no longer supports your version. If you must stay on an unsupported version, utilize long-term support solutions.

00:30:03.490 This will maintain the fork for you and ensure security patches are appropriately applied. If you lag behind on Rails upgrades and find yourself writing your own patches, you risk creating insecure endpoints.

00:30:19.090 The best practice for any security patch is to rely on the Rails team's upstream support. Ensuring your application tracks the most recent Rails version can mitigate surprises during upgrades.

00:30:41.390 If you are also using old, unsupported gems, your upgrade will become even more challenging, as each of those dependencies must be replaced before you can finish the actual upgrade.

00:30:58.080 Ensure that you frequently upgrade your dependencies to remain in line with Rails' requirements. This practice will help prevent you from getting stuck with gems that abandon maintainership.

00:31:12.050 You may also regret using Rails' private APIs. Private APIs are undocumented or contained in private namespaces, allowing Rails to change them without deprecation.

00:31:27.230 If your application depends on them, they might be altered or removed without your knowledge, leaving you with errors. Always prefer using publicly documented methods to ensure you’re working with stable APIs.

00:31:42.320 All of these factors—and more—contribute to the accumulation of debt in your applications. I hope you now feel somewhat encouraged that you too can tackle an upgrade.

00:32:01.540 I know it’s going to be difficult. You may shed a few tears, feel anger, and perhaps curse past engineers who no longer work at your company (I apologize to all of them because I’ve had my moments).

00:32:12.580 But trust that you’re capable. You may be thinking, 'Well, I lean on the Rails core team and work at GitHub; I can't do the upgrade! It’s too hard; we don't have the talent or time!

00:32:25.680 I want you to know this: prior to the Rails 3.2-5.2 upgrade, I had never completed a significant multi-version upgrade and deployed it to production. If I can do it, you can too.

00:32:39.700 I’m not smarter or better than you; I might just be a little bit crazier. Regardless, it's entirely feasible for you.

00:32:55.440 It won't be easy, particularly if you've made cumulative choices that have complicated your process. While you're upgrading, it's critical to remember several key points.

00:33:10.840 You don’t need to resolve all your technical debt issues immediately. You can pay that debt down gradually over time. Tackle that quirky class that perplexes you or uses a private Rails API.

00:33:23.720 Remove or document your monkey patches. Work on identifying out-of-date dependencies.

00:33:36.890 Rails upgrades are a marathon, not a sprint. As you and your team incrementally address the debt you've incurred, the upgrade will eventually become feasible.

00:33:55.850 Remember, you're not alone. Many have completed upgrades before you, and many will follow suit in the future. Find others simultaneously going through upgrades or those who have already successfully completed them.

00:34:10.830 Leverage those contacts for support. I knew Shopify had just finished their hard upgrade and frequently turned to them for advice, asking if this would ever conclude.

00:34:24.230 Finally, remember that the payoff is worth it. Upgrades are time-consuming and difficult, but allowing a fear of upgrading to impede progress won’t change that reality.

00:34:35.820 By upgrading your application, you will put it in a better position, enabling enhanced security, easier hiring, and manageable dependencies.

00:34:52.880 Investing time to upgrade means improved APIs; major version upgrades allow us to rethink how existing features in Rails operate, and this ultimately helps you.

00:35:05.650 For instance, Rails 6 introduced significant enhancements around multiple database handling. Previously, adding multiple databases to an application was cumbersome.

00:35:18.770 With Rails 6, new APIs were created for managing connections and configurations, and without upgrading, you wouldn’t gain access to these improvements.

00:35:33.230 Upgrading also bolstered security—the newer versions introduce valuable security features to protect your applications and users from potential bad actors.

00:35:48.250 In Rails 5, we launched the performance of CSRF tokens, while Rails 5.2 added encrypted secrets, and Rails 6 further enhanced security concerning potential dangerous methods.

00:36:06.470 These features are vital for ensuring your applications remain secure, and the only way to benefit from them is to utilize the latest versions of Rails.

00:36:22.550 While Rails 3.0 grappled with performance issues, later iterations have prioritised faster performance. The Rails team is continuously seeking opportunities to expedite Rails across all environments.

00:36:38.820 Rails 6 is being released alongside fixes for memory leaks during view loading and enhancements in Active Support notifications.

00:36:54.050 Moreover, upgrading Rails provides access to new libraries; Rails 6 introduces components like Action Text and Action Mailbox. Upgrading allows you to utilize excellent new features without needing to reinvent the wheel.

00:37:08.920 In the ideal world, your application will only contain code that pertains directly to your product. If your product is not about sending email, you shouldn't have to write any email-sending code.

00:37:24.150 The framework should inherently manage those elements for you. Upgrading Rails helps maintain that clear boundary between your application and the framework.

00:37:39.300 Finally, upgrading your application opens up opportunities to contribute upstream. Fix bugs, add features, and influence the future of Rails is much harder from an old version.

00:37:56.700 Contributing isn’t a requirement for being on Rails master, but it undoubtedly opens doors that would otherwise remain closed. As DHH stated in 2004 and has reiterated several times since, frameworks should be extracted.

00:38:09.850 We build Rails from existing needs, but if those needs are rooted in Rails 2/3, it becomes challenging to advocate for extractions that your application requires.

00:38:21.650 There are countless good reasons to upgrade, but the most crucial motivation for me throughout the duration of our upgrade was the ability for GitHub to influence the future of Rails.

00:38:34.190 By supporting Rails' future, we also support our future. Looking back at when I began the 3.x to 5.x upgrade, the prospect of being on a modern version of Rails and actively contributing upstream was like an unattainable dream.

00:38:55.700 We were so far behind that I often doubted our ability to finish the upgrade, at least without losing my mind. Granted, that's still up for debate.

00:39:15.420 However, we are now regularly contributing to Rails and supporting its future, which reflects GitHub's current and future stance. Since upgrading Rails, GitHub engineers have submitted over 75 pull requests to Rails 6, enhancing performance, resolving bugs, and adding essential functionalities.

00:39:31.520 Before we tackled the upgrade, we were often compelled to monkey patch or create overly complicated workarounds for bugs. Utilizing Rails 5.2 has not only allowed us to contribute back, but it has also empowered us to make informed choices that benefit our application rather than hinder it.

00:39:49.130 Everyone here benefits from those enhancements as well. In addition to performance improvements and bug fixes, we have also extracted significant functionalities from GitHub.

00:40:04.920 Unfortunately, we don’t have time to delve into technical details, but we’ve refined our database handling for multiple databases in Rails 6. Our knowledge and expertise in managing databases have led to the development of a simple, user-friendly API.

00:40:21.780 This extraction was driven not only by benefits to Rails but also to reduce complexity in our own application. Our goal is to never fall behind Rails again.

00:40:39.460 We're investing in our application and Rails by conducting continual upgrades each week. We regularly bump our Rails gem versions, running all our tests against the new releases to identify regressions and fix them before those versions are released.

00:40:55.990 This proactive approach allows us to simultaneously test GitHub’s code against both Rails 5.2 and 6.0. The rigorous upgrading work we undertook during our major version transition ensures we won't ever fall behind again.

00:41:12.780 Because of this investment, we're confident that Rails 6 is reliable, stable, and resilient. Our ongoing upgrades and contributions to Rails signify that, for the first time in GitHub's history, we’re not just a user of Rails.

00:41:26.620 We’re actively shaping the future of Rails. By extracting code from GitHub and developing new features, we help you scale applications. We also contribute to open source to sustain the Rails framework for the long haul.

00:41:41.420 This approach makes sense for us because it allows us to remain focused on our product while reducing complexity and enhancing resilience—all while giving back to the Rails community.

00:41:58.280 At GitHub, we recognize our responsibility to support Rails. A part of our success is closely tied to the Rails framework, and we possess the influence, expertise, and application to help propel Rails forward.

00:42:10.440 The endeavor to upgrade Rails was a massive commitment; it wasn’t cheap, but the rewards far exceeded the costs.

00:42:24.200 Upgrading Rails unveils numerous opportunities for the future, and I look forward to what the next decade will yield in terms of our contributions to Rails, product development, and the flourishing of our community.

00:42:37.910 At GitHub, we will persist in our investments in the future of Rails and our community, for the sake of necessity, responsibility, and a genuine desire to do so. We are committed to sustainability in Rails because GitHub and Rails are in it together for the long haul.

00:42:53.120 Thank you!

00:43:05.440 I think we have a few minutes, or a minute left, according to the clock, so I can take perhaps one or two questions.

00:43:18.630 The question was: How has the engineering culture evolved now that we're tracking Rails master and actively contributing pull requests?

00:43:33.000 First, we have more privileges than the average company, as we have two members from the Rails core team working on our team. Nobody is going to fork Rails without our consent because we recognize that would not end well.

00:43:48.000 Overall, much of this change has granted our team an opportunity to contribute upstream—a chance that we didn’t have before.

00:44:01.300 This has transformed our culture, as everyone realizes, 'Oh my God! I can contribute to Rails now.' Before, it felt like we could only backport odd features to a fork, which didn't feel as gratifying.

00:44:12.990 I've noticed that even if someone in our team is pressed for time, they manage to carve out moments to contribute, demonstrating excitement for the opportunity.

00:44:34.200 As GitHub employees, we prioritize helping our teams contribute to Rails. It's part of our role, and we strongly advocate for it because it benefits all three parties involved: GitHub, the Rails community, and Rails itself.

00:44:45.500 It's truly a win-win-win situation. I think I have to wrap up.