(bright music) - Hi everyone. - [Audience] Hi. - Thanks for coming to my talk. I know the after lunch slot
can be a little exhausting, but I promise that this
will be fun and interesting. I'm Eileen Uchitelle. You can find me anywhere online
at the handle eileencodes, so that's Twitter, GitHub, I have a blog that I haven't written in in two years, but it exists. (laughs) And if I'm ever gonna write
something, it'll be on there. I'm a staff engineer at GitHub. I work on the application
architecture Ruby language team. We work on setting standards, figuring out how to build
stuff in relative Ruby, and we do a lot of work
to improve the languages and frameworks that we
use as part of Ruby. So we upstream a lot of tooling to Rails, we improve Ruby and performance stuff, so you all get all of
that stuff from us too. I'm on 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. A lot of us are volunteers. Some of us get paid by
our jobs to work on Rails, but for the most part we do
it because we love Rails. The core team is
responsible for figuring out what the future of the
framework is gonna be, what features are gonna
go in the next release, when we're gonna release a release, and all of that good stuff. So each year I reflect
back on what I've learned, the work that I've been doing, and what I'd like to share with you all at conferences this year. So when I started running
the abstract for this talk, I originally thought that
I wanted to talk about the intimate details of
upgrading Rails at GitHub. I had spent a year and a half upgrading GitHub from Rails 3.2 to 5.2, and I certainly could talk
about it for many hours, maybe even days until you were all bored. As I started to explore the
themes around upgrading, I realized that there was a deeper story that I wanted to explore. I started pondering the
following questions. How did we end up so far behind Rails Master in the first place? What past decisions caused our
upgrade to be more difficult? What drove us to even upgrade
when we were so far behind? And what does the future look like now that we're on Rails Master? So the story that I want
to tell you is the story of 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 practically wrote our own version. We fought against the framework. We deviated from the framework, and we even wondered if Rails
was right for us at all. But at the end of the day, Rails is successful because of GitHub, and GitHub is successful because of Rails. Our upgrade didn't just
make for a good blog post for Hacker News to criticize. (audience laughs) The Rails upgrade made it possible for us to use and invest in
Rails for the long haul. We can change and influence
the framework for our needs, while also benefiting the
broader Rails community, and opensource ecosystem. This story is part historical. We'll look back at the
beginning at how GitHub ended up maintaining a
custom fork of Rails too. It's also part technical, exploring what compelled
us to upgrade our process and why it was so difficult. We'll look at the costs of not upgrading and how technical debt
accumulates in your application, until your framework and applications start to work against each other. Lastly, this story is
part forward looking. We'll dive into our effort at GitHub to clean up technical debt,
our commitment to opensource, and our responsibility to
support Rails for the long haul. 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 Ruby Comp 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 went on to talk about his philosophy in building the framework, most notably that many frameworks fail because they are built without
an application in mind. He said that frameworks
are retrospectives. They should be extracted, not built. Rails was attractive and successful, and is attractive and is successful, because it's extracted from
a real application, Basecamp. In the early years, Rails'
complexity grew slowly, and Rails 1.0 was released
in December of 2005. Two years later, Rails 1.2 was released. That same year, Tom Preston-Warner was at a
Ruby meetup in San Francisco when he showed his friend Chris Wanstrath a tool called Grit. Grit is a Ruby tool
that allows you to view, get repositories in an
object-oriented way. It would become the basis
for git repos at GitHub. After seeing Grit, Chris
was immediately hooked, and a few days later, GitHub was born. GitHub was created using
the Rails 1.2.3 version, and after a short beta, GitHub was launched to the
public in April of 2008. The next day, Rails moved from 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 upgrade quickly
to get the new features and bug fixes that that version had, but sometime between 2008 and
2009, GitHub had forked Rails. I couldn't find an exact date, because we vendor our jumps at GitHub, and there wasn't a commit that made it clear exactly
when this happened, but it was sometime
between these two years. I had always thought the
reason that GitHub forked Rails was because Rails 3.0 was slow, and maybe some of you remembered that, but many applications couldn't upgrade because of how slow it was. But it turns out that we had forked Rails long before we even
knew 3.0 was a problem. 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 on Rails Master. Rails just actually wasn't
as stable as it is today. I don't want to go as far as
to say that Rails didn't care about performance or
stability at this time, but I know a lot of app
developers felt that way, and it certainly wasn't a
concern the way it is now. Maybe that's because we were all kind of inexperienced back then, or maybe it was because
Rails was good enough for its most important user, Basecamp. Maybe it was because we, GitHub, didn't contribute enough upstream. I don't really know
'cause I wasn't there but, and I'm not criticizing the past, but it's important that we look at what we did wrong in the past, so we can improve for the future. The problem wasn't, was that
GitHub didn't just fork Rails and add a bug fix here or
performance improvement there, it wasn't a fork with
back ports from upstream. GitHub's fork was Rails with
custom code just for GitHub. It was a different Rails, it was Rails worked into
a different framework that was built for GitHub the way Rails was built for Basecamp, and as GitHub doubled down on their fork and added more and more functionality, of course Rails continued to progress at a fast pace as well, and no one could predict or understand the cost that forking Rails would have on GitHub's application
or engineering team. In 2010, Rails 3.0 was
released, but as I said earlier, many applications couldn't upgrade due to the performance concerns. The performance issues
in 3.0 were a big deal. Users saw an unacceptable
increase in response times. Some applications seeing
requests taking as long, as much as twice as long. Active Record in Rails 3
was found to be slower, five times slower than Rails 2. Despite knowing about
the performance concerns, a GitHub engineer, Aman
Gupta also known as tmm1, started work on upgrading
GitHub from Rails 2.3 to 3, and Ruby 1.9. GitHub hadn't just forked
Rails, we forked Ruby too, which made upgrades way more difficult, and the Rails 3 upgrade wasn't pointing at
Rails 3 Master upstream, it was still a fork of Rails with custom patches from
GitHub added on top, and I can tell you from
experience that maintaining a fork while having to add all of your
features on top of that fork and then also trying to upgrade, is enough to make someone want to quit programming
and be a goat farmer. (audience laughs) So I like, really don't recommend it. In 2012, Rails 3.2 was released and most of the performance
concerns had been fixed by Aaron Patterson and other contributors. In the same year after
performance issues were fixed, GitHub's progress on the
Rails upgrade stalled. It had been two years since
they started the 3.0 upgrade, and the engineering team began questioning whether the effort was worth it at all. They asked each other, why upgrade when this version
isn't causing us pain? Why upgrade when Rails 3.0 isn't so great? Why upgrade when our
fork has more features? Looking at these questions,
the engineering team decided the upgrade wasn't worth their time and focused their effort
on other projects. The truth is that at this time, GitHub wasn't yet feeling
the pain of their fork, and how do you convince
an engineering team to upgrade when they're just, when they're still
feeling very productive? You make your tests faster
when they feel too slow. You refactor a complex class when you need to add new functionality, but when do you upgrade? What's the incentive if the
new version isn't better, and it's working just fine? If you're not feeling the pain of being on a fork or an old version, you're not gonna be compelled to upgrade, and so eventually, all of
these why upgrade questions would become suffocating
for the engineering team. It became harder and harder to find where the framework ended
and the application began, as GitHub engineers started to fight against the fork and the application. Security backports were a nightmare. Each time Rails announced
a new vulnerability, GitHub was forced to manually patch it. Hiring was becoming
increasingly difficult. Nobody wanted to work on
a Rails 2.3 application that doesn't even resemble Rails 2. It's harder to get up to speed, you can't Google search anything. Dependencies were brittle and unsupported as gem authors focused on Rails versions. Development was slow and painful. Working with an application
that's tied so heavily to a custom fork can make adding features or doing refactorings
increasingly difficult. We realized that we needed to
upgrade and get off of fork, because that fork was gonna
suffocate the application. So in 2014, a team of
four full-time engineers, and a few volunteers banded together, wrote an upgrade plan and got to work. It took the team six months of
full-time coordinated effort to upgrade to Rails 3.0 and
deploy it to production, and a few months later, they deployed Rails 3.2
to production as well. It's important to remember
here that 3.0 and 3.2 are still a fork with GitHub
custom patches added in. By this time, the Rails 3 series was only receiving
severe security patches, so even though the upgrade was a success, the code base and the fork
were still very far behind. The effort put into upgrading
from 2.3 to 3.2 was massive, and motivation dwindled after that. It would be another two years before the Rails 4.0 upgrade was started. That same year, Rails 5.0 came out. I'm sure to some it felt like
GitHub would never catch up if Rails was constantly improving and always releasing new versions. In 2017, I joined GitHub. (audience laughs) At this point, the Rails 4.0 upgrade
was not in a good place. There was no dedicated team working on it. The upgrade had fallen by the wayside, and so on my first day
I asked people Hubot, "Hey, run the Rails 4 test,
I want to see how bad it is." And so we do it and Hubot says, "Hey, there's more than
4,000 errors going on here." (laughs) Luckily Hubot can't count
and it's more like 2,000 so that really easy, right? (audience laughs) Nothing. After the 3.0 upgrade, GitHub engineers had added some tooling that made Rails upgrades easier. We had a system that allows us
to dual boot the application in multiple Rails versions. If you've seen Shopify's talks on this, we use a similar system to
them, but it's different. This meant that we didn't need to maintain long running branches. By adding the ability to
dual boot the application, we could focus just on test failures, instead of working with merge conflicts. Unfortunately, this method
requires us to hack Butler, but I would rather hack Butler than have a fork of Rails,
so that's worse. (laughs) With this method we're able to
boot the server, the console, and run all of the tests
in multiple Rails versions, which makes it easy to
compare and contrast behavior between the version that's in production, and the version that we're upgrading to. It also allows us to
incrementally upgrade Rails and prevent regressions. Whenever we have a build that's green, we make it required so that everyone has the right code and the new version, the version we're upgrading
to and the old version. So when the 4.0 build was green, we'd swap it our for 4.1 and
we'd get to work on that, and then we'd swap that out and you'd have to write
code for 3.2 and 4.1, and that's how we did it. So we could prevent new regressions in the code base for that version. In the application code,
we used helper methods to easily condition
different Rails versions. We always put the production
version in the if clause, and all of the future code in the else. When we upgrade to 4.2, then the same tests that
we already fixed in 4.0 won't start failing in the
3.2 branch of the code. In March of 2018, three months, a year and three months
after I started at GitHub, we deployed Rails 4.2 to production with zero downtime and
limited customer impact. After deploying 4.2 to production, I wanted to get started on 5.0 immediately because I didn't want us to lose momentum, like we were so close, but I
was honestly very burned out. I had been the only engineer working full-time on the Rails upgrade, and I had a lot of other
engineers helping me out, but they were on a volunteer basis. I couldn't force them to do the upgrade. Upgrading Rails was
difficult and a lonely task, and I decided that there was no way that I would do the 5 series alone. So for the Rails 5 upgrade, we had a team of four full-time engineers, and by this time I had learned what processes worked
and what ones didn't. So I used GitHub Projects
and a tool that RCI has to create unique issues for
every single unique failure, so that we could track progress
and prevent duplicated work. This also meant that
any of those volunteers could easily just pop in,
grab an issue, fix it, and then move on without having
to ask me what to work on. Because we had a dedicated
team and a streamlined process, the upgrade from 4.2 to
5.2 took only five months, and in August of 2018, we
deployed 5.2 to production with zero downtime and no customer impact. We had learned a lot. Oh, yes you can clap. (laughs) (audience applauding) We had learned a lot from the 4.2 deploy, and we were a lot less nervous
about deploying 5.2 than 4.2. We took a few months
to actually deploy 4.2, because we hadn't done it before and we didn't know what we
should be worried about, but once we were on 5.2, we
just kind of pushed it out. This was a huge milestone. It was the first time in 10 years, 10 years that GitHub
wasn't on a fork of Rails. It was the first time in 10 years that GitHub was on the most
recent version of Rails. That's 10 years of
cumulative technical debt, 10 years of fighting our
fork in our application. We had finally started
to pay that debt off. By upgrading, we didn't
eliminate technical debt, but we crated breathing room that the application
hadn't had in a decade. I hope that learning about our upgrade hasn't scared you into not doing your own. The point of this talk isn't
to tell horror stories, it's to show you that there's
a cost to not upgrading, and that cost is cumulative. After hearing about the
Rails upgrade at GitHub, I had a lot of engineers
come up to me and ask me how they can convince
their leadership team to prioritize an upgrade along
with the feature development. They don't have the resources
or it's not in their roadmap. It's not a priority for the company, or they think it's just
gonna be too expensive. It's true that upgrading is
expensive and time consuming, and I'm not going to lie to
you and tell you otherwise. It's easier to say this upgrade will need X number of engineers, at Y number of dollars an
hour, for Z number of hours. You can measure this cost, and decide whether this
is too expensive or not, but at the end of the day, it doesn't matter how expensive the dollar amount of upgrading
your application will be, because the cost of not
upgrading is immeasurable. Not upgrading your application will eventually cost more
money than any upgrade because of the way the debt
accumulates in your application. When you don't upgrade Rails, you have to become a security expert. The Rails core team only supports patching security vulnerabilities in the major current version, and the major version before that. So currently, we only support
Master, 5.2, 5.1. 5.0 and 4.2, but when 6.0 comes out, 4.2's gone. Like, we're not gonna support it anymore, and I know a lot of you
in this room are on 4.2, 'cause I've met a lot of
people who are on 4.2, so I assume that you are all on 4.2. If you're using that version, then your team ends up being
responsible for understanding and patching the security
vulnerabilities yourself. It's very hard to get those right, because we on the Rails
team aren't gonna outright reveal how to exploit the vulnerability, so that we can protect users of Rails who haven't upgraded yet. Not upgrading requires you and your team to be responsible for patching
security vulnerabilities. When you don't upgrade Rails,
you lose out on great talent. Bootcamp grads, college grads,
all kinds of new engineers that are coming into Rails
are not learning Rails 2.3, and they're certainly not
learning your weird custom fork. (audience laughs) Those engineers not only don't want to work on an old version, they just don't have the knowledge to understand how it worked. Engineers will turn down the
opportunity to work for you if you're on an old version, because that version doesn't
let them contribute upstream, it's no longer Googleable,
and it's 10 years old. When you don't upgrade, some
of the gems that you rely on will get abandoned and deprecated, so you'll either have to live with bugs, or fork yet another dependency. Don't get me wrong, the answer to this problem
is not roll your own. New gems may not support
old versions of Rails, so you won't even be able to use those if you're on an old, unsupported version. This makes development so much harder. Every choice and dependency
becomes more and more difficult, because you're so far behind. Maintaining old gems on
top of your old framework gets tedious very quickly. I mean, you don't upgrade Rails, you end up building more
and more infrastructure on top of your fragile application. I've seen this firsthand at GitHub. We have tons of infrastructure
code in our app, multiple databases, CI
tooling, our own job queue, and probably things
that I have yet to find. Ideally, your application would consist only of code that makes up your product. GitHub's value is not in that we have code to make multiple databases run, our value is in our community,
our issues, our repos. Multiple databases allows us to keep our application up and running, but it is not why people buy our product. This infrastructure code makes
development more painful, because of how tightly it couples our application to Rails' internals. Minor changes can easily turn into major refactorings or abandoned projects, but the biggest cost of not
upgrading Rails is that someday, someone at your company will decide that using Rails was a mistake, and that it's time to carve your application
up into microservices. (audience laughs) Now, this isn't a language war talk. I'm not criticizing Go,
you want to write Go, that's fine, I don't care. (audience laughs) But we're at RailsConf, so
I'm going to at least assume that you like writing with Rails. I love writing Rails. I want to keep getting
paid to write Rails, and it might seem like an exaggeration, but if we don't upgrade Rails, we don't get to keep writing Rails. The Rails ecosystem won't improve, our applications will degrade, and we'll be faced with
an expensive rewrite, and if you think upgrades
cost a lot of money, rewrites come with a
hefty price tag as well. They might even cost you your job. The key to upgrading Rails
is to incrementally pay off cumulative technical debt
that you've incurred, and then figure out a plan
to keep that debt paid down. I won't stand here and tell you that upgrading Rails will be easy. I'll leave that to the
person on Hacker News who wondered why I couldn't do it faster because their upgrade took a weekend. (audience laughs) Clearly, we're doing something wrong. The upgrade did take a long time, but it wasn't the only
thing that we worked on during this period of time. I took time to delete features, I rewrote our custom test framework, I improved our handling
for multiple databases, and tests and development. It's unfair for anyone to
look at our upgrade timeline, and decide that using
Rails is too expensive. We made choices at GitHub
that made upgrading harder. You have made choices in your applications that will make upgrading harder, but that doesn't mean that
Rails is a bad choice. Technical debt is real, and you and your team
need to make decisions about what technical debt is acceptable, and what needs to be cleaned up. At GitHub, we decided that
being behind Rails Master is no longer technical debt that we're willing to put up with. You can slowly work on technical debt and upgrade Rails to get your
application in a better place. There are a few things that you should consider when upgrading, and mistakes that you want to avoid, so you don't end up doing a seven year upgrade
like we did at GitHub. The first most important
step is to build out a team. Upgrades are really difficult, and it helps to have a team
that can support each other, bounce ideas off of, and make sure the motivation stays up. If you have a one person upgrade team, and that person leaves the company, the upgrade is gonna stop or
at least be severely stalled. Make sure to create redundancy and support for such a difficult and lonely task. If you have a small team and
you really need to upgrade, consider hiring a contracting
firm like Testable, to help you get out of the weeds. It will be expensive, but
cheaper than not upgrading. They also can help you
institute best practices, so that you don't end up so far behind Rails Master in the future. You can also makes Rails upgrades easier by taking the time to plan your upgrade. Your team should ask, do we want to upgrade incrementally
from 3.2 to 4.0 to 4.1? Or do you want to just rip the bandaid off and go straight to 5.2? You may want to use incremental upgrades, because then you can see
deprecation warnings, or you may just want to say, our tests are awesome
and we can just do it. Our upgrade at GitHub, I knew
it was gonna be long enough that it made sense to work incrementally, so that we could stay motivated. If we had tried to go straight to 5.2 and it would take more than a year, it was gonna be kind of
difficult to convince leadership that we should keep doing it. It's kind of like, oh look, we did it, and then we did it again,
and again, and again. So, they were all happy
about that. (laughs) You should also consider that if you want to do
the two branches thing, or if you want to have a dual booting CI, the dual booting CI can really help you pay debt down upfront, so that you make your
future upgrades easier. If you do the long running branch, sometimes that can be really difficult to keep up with features
that are going into master. You can also make your upgrades easier by fixing deprecation warnings early, instead of ignoring them to
take care of the next version, consider fixing them as
soon as you see them. Some deprecations are
related to major changes, and they'll actually block your
upgrade until you fix them. If you have ever worked with
Alias method chain deprecation, your app basically just can't boot if you have that deprecation warning, so you want to fix that
before you get to the point where you just have to
wait for those to be fixed, because if you have, if you fix them, then you can see all of the failures and know how far behind you are, otherwise you're just stuck with Alias method chain
for your entire life. (audience laughs) Once you've upgraded to
the most recent version, make a plan for future upgrades. How often is your team willing to upgrade Rails in the future? Are you interested in
testing new releases of Rails in the beta or release candidate phase? This can help make upgrades
smoother for everyone else, because you can tell us on
the Rails team what was hard, and we can fix it before
you release that version. If you can't run Rails
Master in production, can you invest in a dual booting CI, so that you can test Rails 5.2
and Rails 6 simultaneously? If you invest in an upgrade, it makes sense to invest
in tooling for the future, so that you can stay out of upgrade debt. So now that we've looked at considerations that you should take when upgrading, we'll now look at things
that you will regret and should not do. (audience laughs) There are a lot of choices that you can make in your application that will make upgrades or maintaining your application
a lot more difficult. Something that you're likely
to regret in the future is forking Rails. (audience laughs) Don't do this. The choice to fork Rails
and deviate from upstream was the single most expensive choice we made at GitHub in
regards to our application. This had a compounding effect on the state of their code base
that made our upgrade take, our upgrade from 2 to 5 take seven years. If you absolutely must fork Rails, you should try to at least track the upstream version
as closely as possible, and only backport bug fixes
or features that you need. If you add features that you never intend
to upstream to Rails, your fork is gonna deviate from upstream and make upgrading really difficult. You also may regret falling
behind on security upgrades, until the point where Rails no
longer supports your version. If you need to stay on an
unsupported version of Rails, you should at least use something like Rails Longterm Support, because they'll maintain the fork for you, and ensure that the
security patch is correct. If you fall behind on Rails upgrades and end up writing your own patches, you may do it wrong and
leave an insecure endpoint. In general, the best way
to do any security patch is to rely on Rails upstream. Ensuring your application tracks the most recent version of
Rails can reduce any surprises when you upgrade for that security patch. If you're also using old unsupported gems, your upgrade will be more difficult because you hae to replace
each of those dependencies before you can finish your upgrade. Ensure that you upgrade
your dependencies often to keep in mind with Rails' requirements. This also prevent you
from ending up using a gem that gets abandoned by its maintainer, because Rails isn't going to require a gem that is no longer maintained. You may also regret
using Rails private APIs. In Rails, private APIs
are code that is purposely undocumented or under
the private namespace. We reserve the right to change these APIs without deprecation, so if your application is relying on them, they could be removed or changed
and you won't actually know except for having an error. It's always best to use
public documented methods, so that you know the Rails
team will deprecate them if we ever intend to
change or remove them. So all of the things that
we looked at and more can compound the cost of your upgrade. It's easy to see how these decisions cause us to accumulate
debt in our applications. I'm hoping by now, that you're feeling a
little bit more confident that you too can do an upgrade. I know it's going to be hard. You might cry. You'll definitely get angry. You may even curse past engineers that no longer work at your company. I did, I apologize to all of you. (laughs) But I want you to know that you can do it. I have faith in you. You may be thinking, okay, well Eileen, like you're on the Rails core team, and you work at GitHub, and I'm not capable of doing the upgrade. It's too hard, and we just don't have
the talent or the time. So I'm gonna tell you something that I've told a lot of
people, and it's true, and it's not because I want
to pat myself on the back and have you all clap for me, but it's because I want you
to know that you can do this. Before the Rails 3.2 to 5.2 upgrade, I had never done a major
multi version upgrade before, and deployed it to production. If I can do it, you can do it. I'm not smarter than you. I'm not better than you. I just might be a little
bit crazier than you. (audience laughs) But you can totally do it. It's not gonna be easy, especially if you've
taken on cumulative costs that we looked at earlier. While you're upgrading, it's really important to
remember a few things. You don't have to solve all of your technical
debt problems tomorrow. You can pay that debt down
incrementally over time. Start with that weird class that you don't know what it does, or that uses a private Rails API. Remove or document your monkey patches. Identify and upgrade Rails dependencies that are out of date. Rails upgrades are a marathon,
they are not a sprint. If you and your team
incrementally pay down debt, the debt that you've incurred, over the debt you've incurred, the upgrade will eventually
be possible and completed. It's also important to
remember that you're not alone. Many before you have done an upgrade, and many after you will do an upgrade. Find others doing
upgrades at the same time, or folks that have done it in the past and lean on them for support. I knew that Shopify had just
finished their own hard upgrade and so I had them to ask like, "Hey, is this ever gonna be over?" (audience laughs) Or advice how to continue, and lastly, remember that
the payoff is worth it. Upgrades take a long time
and they're really difficult, but being afraid of upgrading
isn't gonna make it go away. When you upgrade your application, it'll eventually be in a better place. In addition to improved security, easier hiring, and more
manageable dependencies, doing the hard work of upgrading will give you improved APIs. Major version upgrades allow us to rethink how previous features in Rails worked, and redesign them, and rework them, so that we can improve them for you. An example of an improved API in Rails 6 is the handling for multiple databases. Before Rails 6, adding multiple
databases to an application was awful and very hard. You had to write a ton of
code yourself, but in Rails 6, we've added new APIs for
establishing connections, as well as an improved API for active record database configurations. Without upgrading, you don't have access
to these improvements. Upgrading to new versions of
Rails also improves security. In addition to security upgrades being easier if you're not behind, Rails also adds new security features to protect your applications
and your users from bad actors. In Rails 5, we introduced
performance CS or tokens. Rails 5.2 introduced encrypted secrets, and Rails 6 is shipping
with improved security around potentially dangerous RO methods. These features will help keep your applications safe and secure. Since these are security features and they're not vulnerability patches, the only way to get them is to
be on a new version of Rails. And although Rails 3.0 was
plagued by performance issues, newer versions of Rails have
focused on better performance. The Rails team is always looking for areas to make Rails faster in all environments, and Rails 6 is shipping
with a memory leak fix for view loading and development, and faster active support notifications, and other stuff that I cannot remember. (audience laughs) Upgrading Rails also gives
you access to new libraries. Rails 6 is shipping with
new parts of the framework, like action text, active action mailbox, one of the mailboxes, (audience laughs) and Zeitwerk. By upgrading, you can rely on
great new features in Rails without having to build your own infrastructure
tooling in your application. In an ideal world, your application would contain only code that
pertains to your product. If your product isn't about sending mail, you shouldn't have to
write code that sends mail, the framework should just do that for you. Upgrading Rails helps you keep that line where your application ends and your framework begins crystal clear, and lastly, upgrading your application gives you a chance to contribute upstream. It's really difficult to
fix bugs, add features, and influence the future of
Rails from an old version. It's not a requirement to contribute if you're on Rails Master, but it definitely helps open doors that are otherwise closed. As DHH said in 2004, and many times since, frameworks are extracted. We build Rails from our existing needs, but if those needs are
set back in Rails 2.3, it's hard to make a case for extraction that our application requires. All of these are good reasons to upgrade, but this is the one that kept me going. This is the reason that I spent a year and a
half on the Rails upgrade. It was so that GitHub could
influence the future of Rails. For GitHub, this is the biggest and most important reason to upgrade. By upstreaming features, fixing bugs, and supporting Rails' future,
we support our future as well. When I look back at when I
started the 3.2 to 5.2 upgrade, the thought of being on a
modern version of Rails, and actively contributing upstream felt like an unachievable fairytale. We were so far behind, that often I wasn't sure
that we could finish it, at least not while maintaining
the majority of my sanity, although that's still questionable. But now regularly contributing to Rails, and supporting the future of Rails is GitHub's present and future state. Since upgrading Rails, GitHub engineers have sent
over 75 pull requests to Rail 6 that improved performance, fixed bugs, and added major functionality to Rails. Before we upgraded, we were
often forced to monkey patch, or work around bugs in
overly complex ways. Using Rails 5.2 has allowed us to not just contribute
upstream, but to make choices that improve our application
instead of hinder it, and all of you here benefit
from those changes as well. In addition to bug fixes and
performance improvements, we've extracted major
functionality from GitHub. We don't have time for technical details, but we've extracted our handling for multiple databases in Rails 6. We've used our knowledge and
expertise on database handling to create an easy to use, robust, new API for defining, establishing,
and switching connections between databases in your application. We did this extraction not
just because it benefits Rails, but because it allows
us to reduce complexity in our own application. Our goal is to never
fall behind ever again. We're investing in our application and in Rails by doing continuous upgrades. Every single week, we bump our Rails gem, and run all of our tests
against the new version. That lets us find
regressions in Rails quickly, and fix them before we
release that version. It also lets us test all of GitHub's code in Rails 5.2 and 6.0 simultaneously. Since we did the hard work of upgrading these major versions, this new process means that
we won't fall behind again, because our upgrades are easy and we're doing them as Rails changes instead of many years later. Because of this, we're
confident that Rails 6 is performant, stable, and resilient. Continuous upgrades and
our contributions to Rails are evidence that for the
first time in GitHub's history, we're not just using Rails or simply building a Rails application. For the first time in GitHub's history, we're pioneering the future of Rails. We're extracting code from GitHub, building new features into Rails that will help you scale your application, and giving back to opensource to support Rails for the long haul. It makes good sense for us to do this. Not only do we give back to the community, but it helps us keep our application focused on our project or product. We can reduce complexity
and improve resilience, all while contributing
to the future of Rails. At GitHub, we not only need to do this for our own application on our own needs, but we have a responsibility
to support Rails. We owe part of our success
to the Rails framework, and we have the influence,
expertise, and application to help push Rails forward. Upgrading Rails was a huge investment. It wasn't cheap, but it was so worth it. Upgrading Rails opens up a ton of possibilities for the future, and we have a bright path ahead of us. We're building features faster. We're more confident
our code base is stable. We're improving the scalability to Rails, and we're giving back to
the opensource community. At a minimum, by upgrading, we went from being crushed
by our application, Rails, and the decisions that we'd made, to building up our application,
to building up Rails, to building up our community. Upgrading Rails gave us
the freedom and flexibility that we didn't have before. It empowers our engineers to
build more and build better. In 2007, GitHub was
born and 11 years later, we're finally tracking master. It took seven years from the
day the 3.0 upgrade was started to the day the 5.2 upgrade was complete. The future is bright
and I can't wait to see what the next 10 years allows
us to extract from GitHub, build in Rails, and how
our community thrives. At GitHub, we'll continue to
invest in the future of Rails and our community because we have to, because we need to,
and because we want to. We'll continue to invest in the future because GitHub and Rails are in it together for the long haul, and I hope you are too, thank you. (audience applauding) I think we have three
minutes or a minute left, according to that clock, so I could take probably
one or two questions. The question was how has the
engineering culture changed now that we're tracking master with waiting for pull
requests into Rails and stuff. So first, we have more privilege
than the average company because we have two people from the Rails core team
working on our team, and no one is gonna fork Rails without coming through
us first, because... (audience laughs) It wouldn't go well. But you know, I think that
most of what it's done is it's given folks an opportunity to contribute upstream that
they didn't have before, and it's changed our culture
in that everyone is like, "Oh my god, I can
contribute to Rails now." Because before it was like, I guess I can backport some
weird stuff to this fork. It doesn't feel as good, so I think that having
that access to do it, even if they don't, even if
someone doesn't have the time, I've seen engineers make time for it, because they're excited about it, and we, our team is totally
100% there to help them do that. So, if of the other GitHubbers
in here aren't aware of that, we'll help contribute upstream to Rails, that's part of our job, and
we push really hard for that because it benefits us,
and it benefits GitHub, and it benefits Rails, so it's a win, win, win situation. (audience laughs) I think I have to be done. (laughs) (audience applauding) (upbeat music)
