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.