Duration 40:15
16+
Play
Video

RailsConf 2019 - The Past, Present, and Future of Rails at GitHub by Eileen M Uchitelle

Eileen Uchitelle
Staff Software Engineer at GitHub
  • Video
  • Table of contents
  • Video
RailsConf 2019
April 30, 2019, Minneapolis, USA
RailsConf 2019
Request Q&A
Video
RailsConf 2019 - The Past, Present, and Future of Rails at GitHub by Eileen M Uchitelle
Available
In cart
Free
Free
Free
Free
Free
Free
Add to favorites
6.1 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speaker

Eileen Uchitelle
Staff Software Engineer at GitHub

Eileen M. Uchitelle Senior Systems Engineer at GitHub. Her focus is to ensure applications and code are secure and fast. She is an avid contributor to open source focusing most of her energy on improving the Ruby on Rails framework. She's is a member of the Rails Core team and the Rails Security team.Eileen is also a speaker and has presented at many conferences on performance, Active Record, and contributing to Rails.

View the profile

About the talk

RailsConf 2019 - The Past, Present, and Future of Rails at GitHub by Eileen M Uchitelle


On August 15, 2018 GitHub was deployed to production running Rails 5.2. This was a historic event; for years GitHub had been behind Rails and dependent on a custom fork of Rails 2.3. This talk will visit GitHub's past, including our tumultuous relationship with the Rails framework, and the grueling effort it took to get our application on the latest version. You’ll learn what mistakes to avoid and the reasons why such a difficult upgrade was worth it. We’ll explore what tracking master means for the future and establish that GitHub and Rails are in it together for the long haul.

Share

Hi, everyone. Thanks for coming to my TED Talk. I know that after lunch slot can be a little exhausting but I promise that this will be fun and interesting. I'm Eileen. You should tell you can find me anywhere online at the handle Eileen codes. So that's Twitter get home. I have a Blog that I haven't ran into years but it exists and if I ever going to write something on there, I must engineer at GitHub. I work on the application architecture Ruby language team. We work on setting standards of figuring out how to build stuff in rousing Ruby and

we do a lot of work to improve the languages in Frameworks that we use as part of her being so we are stream a lot of cooling to improve performance stuff. So you all get all of that stuff from us to I'm on the rails core team for those of you who are new to rails and haven't heard of the core team as 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 quora team is responsible for figuring out what the

future of the framework is going to be what features are going to go in the next release when we're going to release the release and all of that good stuff for 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 and get him. I had spent a year-and-a-half upgrading get help from Ralphs 32252 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 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 does what past decisions caused our upgrade to be more difficult? What drove us even upgrade when you're so far behind and what does the future look like now that we're on rell's master. So the story that I want to tell you is the story of the past present and future of Rousey GitHub. We've been using rails at GitHub

since day one and at times rails and get others had our differences many years ago. We for Thrills and practically wrote our own version. We fought against the framework we deviated from the framework and we even wondered if it was right for us at all. What are the end of the day rails is successful because of GitHub and get have a successful because of rails our upgrade didn't just make for a good blog post for Hacker News to criticize. The rails upgrade made it possible for us to use and invest in rails for the Long Haul. We can change an

influence the framework for our needs while also benefiting the broader rails community and open source ecosystem. This story is part historical will look back at the beginning and how get up ended up maintaining a custom forged rails to is also part technical exploring what compelled to upgrade our process and why it was so difficult to the costs of not upgrading accumulates in your application until your framework an application start to work against each other last of the story is part forward-looking effort. I get home to clean up technical debt our

commitment open source and our responsibility to support rails for the Long Haul. First let's go back in time to the beginning. In 2004. Dhh announce a new Ruby framework called Ruby on Rails immediately rails caught the attention of the Ruby community at Ruby cost at your dhh talked about rails its history how it came to be and of course, why was better than existing Ruby Frameworks? Do it on this hog about his philosophy in building the framework. Most notably that many framework spell because they are filled out an application in mind. He said that Frameworks or retrospective

they should be extracted and not build rails was attractive and successful and is attractive and is successful because it's extracted from a real application. Is it really yours real complexity Bruce Boli's and rails 1.0 was released in December of 2005 to years later Rose, 1.2 was released that stain. Your Tom preston-werner was out of every meet up in San Francisco when he showed his friend Chris Wings Rapid tool called Grit. Where is Ruby tool that allows you to view get repositories in object-oriented way it would become the basis for get repost GitHub.

After seeing great Christmas meeting Lee hooked and a few days later. I was born I was created using the rails 1.2.3 version and after a short beta get hot was launched to the public in April of 2008 the next day rails moved from their own a savannah server to get hub. In 2009 rails 2.3 was released in the early days when rails would release a new version upgrade quickly to get in the new features and fun fixes that version had but sometime between 2008 and 2009 get up at 4 Trails. I couldn't find an exact date because we've been there are gems and get home and there wasn't a

commit that made it clear exactly between these two years. I had always thought the reason that get hug for Trellis was because Ralph's 300 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 the way before we even know 3 hours a problem. Never member. It was a wild west rail startups. No one really knew what the future of Rouse Argueta was going to be. We weren't you talking about the importance of upgrades or staying current on Route Master reels just

actually wasn't as stable as it is today. I don't want to go as far as to say that rail 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 cuz you're all kind of an experience back then or maybe it was because rails was good enough for two most important user base count. Maybe it was because we get hug didn't contribute enough Upstream. 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 that we can improve for

the future. The problem wasn't was that kid of didn't just work Rosen at a bug fix here performance Improvement there. It wasn't a fork with backwards from Upstream work was Rouse with custom code just forget. It was a different rails Israel's war II to a different frame worth. It was built for GitHub the weight rails with build for Basecamp. And I was going to double down on their forked out of more and more functionality, of course rails continue to progress as a fast at a fast pace as well and no one can predict or understand the cost that working rails when I get home to application

or engineering team. In 2010 RX300 was released but as I said earlier many applications can upgrade due to the performance concerns and issues in 3 / big deal user saw and unacceptable increase response times some application seeing request taking as long as much as twice, as long as three was found to be slower 5 times slower than rails to. Despite knowing about the performance concerns of engineer on Gupta also known as tm1 started work on upgrading GitHub from rails 2323 and Ruby want to get up. I'm just bored Grill before

grooming to which upgrades way more difficult. Real 3 upgrade wasn't pointing at railstream master of stream. 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 Ford. And then also trying to upgrade is enough to make someone want to quit programming and be a goat farmer. So I like really don't recommend it. In 2012 RS3 200 lease and most the performance concerns have been fixed by Aaron Patterson and other contributors in the

same year after performance issues were fixed. It has been two years since they started the 300 upgrade and the engineering team began questioning. What are the effort was worth it at all other than causing his pain. What happened on Route 3? I wasn't so great. Why don't we want our Fork has more features? Look at these questions, the engineering team decided the upgrade wasn't worth their time and focus their effort on other projects. The truth is that this time get up wasn't get feeling the pain of their fork. And how do you convince engineering team

to upgrade when they're just they're still feeling very productive. You make your test faster when they feel too slow. You were Factor 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 out of work or an old version, you're not going to be compelled to upgrade. Eventually, all of these why upgrade questions would become a suffocating for the engineering team if he can harder and harder to find where the framework ended any application

began as it started to fight against the fork and the application security backwards word nightmare each time a difficult. Nobody wanted to work on a rails 3223 application that doesn't even resemble rails to it's harder to get up to speed anyting dependencies Roberto on unsupported Jim authors focused on new rails versions development with an application that's tied so heavily to a custom for adding features or increasingly difficult. We realized that we needed to upgrade I get off of work on that Ford was going to suffocate the application. Do in 2014 a team of four

full-time engineers and a few volunteers bana together Rowan upgrade plan and got to work. It took the team 6 months of full-time coordinated effort to upgrade to Route 300 and deployed to production and a few months later. They deploy rails 322 reduction as well. It's important to remember here that 300 and 32 or still at work with GitHub custom patches added in By the time the rails 3 Series was only receiving severe security patches. So even though the upgrade was a success the code base and a fork. We're still very far behind.

The effort what is upgrading from 23232 was massive and motivations Windows after that would be another two years before the rails. 400 upgrade was started that same year as Five-O came out. Archery Summit felt like GitHub would never catch up and browse was constantly improving and always releasing new versions and 2017. I doing to get hub. This point the rails for upgrade was not in a good place. There was no dedicated team working on it the upgraded Fallen by the wayside and so on my

first day I asked you but hey run the rails for test. I want to see how bad it is. And so we do it and you got says hey, there's more than $4,000 is going on here. What do we do about can't count? It's more like 2,000. So that's really easy, right? After the 300 upgrade get an engineer's it added some tooling that made rails upgrades easier. We had a system that allows us to do a booth application in multiple rows versions if you've seen shopify's talks on this, but it's different. This meant that we didn't need to maintain

long-running branches by adding the ability to do boo the application you can focus just on test failures instead of working with merge conflicts. Unfortunately, this matter requires us to hacks on there, but I would rather have on there than have a fork or else so Of course. Another were able to beat the server the console and run all of the tests in multiple World versions, which makes it easy to compare and contrast Behavior between the version that they production in the version. They were upgrading to it also allows it to incrementally upgrade rail to prevent

regressions whenever we have a bill that's green. We make it required to it. Everyone has to write code in the new version and then there were two were upgrading to in the old version. So when the 400 build with green we swap swap it out for for wanting to get to work on that and then we spot that out here at the right code for 32141. That's how we did it so that we can prevent for that version. Any application code reuse helper methods to easily condition different routes versions. We always put the production version in the if clause and all of the future code in the else

when we upgrade before 2, then the same test that we already fixed before I won't start feeling in the 3-2 Branch the code in March of 2018 three months a year and three months after I started to get hope we deployed Real Sports YouTube reduction with zero downtime and limited customer impact. After the point Fortuna production, I wanted to get started on the en500 immediately because I didn't want us to lose momentum like we were so close, but I was honestly very burned out. I have been the only engineer working full-time on the rails upgrade and I have

a lot of other Engineers helping me out, but they were on a volunteer basis. I couldn't force them to do the upgrade upgrade eyebrows with 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 the time I was working but once didn't so I use GitHub projects to Anatole at RCI has to create unique issues for every single unique failure that we can track progress and prevent duplicated work is 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're dedicated team and a streamlined process the upgrade from 4 to 5 to took only 5 months and in August of 2018. We deployed 522 reduction with zero down time and no customer impact. We learned a lot. We learned a lot from the Fortuna play and we were a lot less nervous about the Flying V 2014. We took a few months to actually to play for 2 because we had not been done before and we didn't know what we should be worried about but what to wear on 5/2, we just kind of pushed it out. Is it a huge

milestone? It was the first time in ten years 10 years that GitHub wasn't on a fork of rails. It was the first time in ten years ago. I was on the most recent version of rails that's 10 years of cumulative technical debt 10 years of fighting our fork in the our application. We had finally started to pay that debt off by upgrading we didn't eliminate technical debt, but we created breathing room with the application. Hadn't had in a decade. Although learning about our upgrade hasn't scared you into not doing your own. The point of this talk isn't as hell horror stories is 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 have had a lot of Engineers come up to me and asked 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 there. It's not a priority for the company or they think it's just going to 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

engineer's 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. What are 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 breathing is immeasurable. Not bring your application will eventually cost more money than any upgrade because of the way the debt accumulation your application. When you do you have to become a security expert only supports patching security vulnerabilities in the major current version and the major

version before that so currently the only support but Master 525 150 and for 2 but 160 comes out where she's gone. We're not going to support it anymore. And I know a lot of you in this room are on for too cuz I've got a lot of people to run for 2, so I assume that you are on for 2. If you're using that version, then your team as a being responsible for understanding and patching of the security vulnerabilities yourself. It's very hard to get this right. Because we on the real team are going to outright reveal how to exploit the vulnerabilities that we can protect you

upgraded yet. Not you and your team to be responsible for the patching security vulnerabilities to 3, and they're certainly not learning. You're weird custom Fork. Those engineer's not only don't want to work on an old version. They just don't have the knowledge to understand how it worked as an earful turn down the opportunity to work for you. If you're on an old version because that person doesn't let them contribute Upstream. It's no longer available and it's 10 years old. When you don't upgrade where you were some of the gems that you rely on will get

abandon and deprecated. So you'll either have to live with bugs or forget another dependency. I don't get me wrong. The answer to this problem is not to roll your own. New gems may not support old versions of real 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 Independence. He becomes more and more difficult because you're so far behind maintaining old gems on top of your old framework gets tedious very quickly. How many total grade rails you end up building more and more infrastructure on top of your

fragile application. I seen this firsthand of GitHub. We have tons of infrastructure code in or out multiple databases. We think that I have yet to find ideal your application would consist only of code that makes up your product and I was value is not in that we have code to make multiple databases run our values in our community. Our issues are repos multiple databases allows us to keep her application up and running but it is not why people buy our product. December structure code makes development more painful because of how tightly a couple of our application to rails internals

minor changes can easily turn into major factories were bending projects. The biggest cost of not upgrading rails is that someday someone at your company will decide that using roses a mistake and then it's time to carve your application up into microservices. Now this isn't a language more talk. I'm not criticizing. Do you want to go that's fine. I don't care. But we're real talk. So I'm going to at least assume that you like riding rails. I love riding rails. I want to keep getting paid to write rails and it might seem like an exaggeration but we don't upgrade rails. We don't get to keep

writing rails. The real ecosystem would improve or applications will degrade I will be faithful inexpensive rewrite a lot of money first, the price for a happy price tag as well. They might even cost you your job. Makita upgrading rails is to incrementally payoff 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 who wondered why I couldn't do it faster because they're afraid took a weekend. Clearly

we're doing something. The upgrade did take a long time, but it wasn't the only thing that we worked on during this. Of time. I took time to delete features. I reword some test framework. I improved are handling for database databases intestine development. It's unfair for anyone to look at our upgrade timeline and decide that using Rouses too expensive. We made choices that get them made upgrading harder you have made choices in your application 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 at what needs to be cleaned up I get her but we decided that being behind routemaster is no longer technical debt that were 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 few things that you should consider when upgrading and mistakes that you want to avoid so you don't end up doing a 7-year upgrade like we did it get home. 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 and make sure the motivation stays up if you will one person upgrade team and that person leaves the company the upgrade is going to 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 me get out of the weeds. It will be expensive but cheaper than not upgrading. They also can help you Institute best practices that you don't end up so far behind Wells master in the future. Are you also make rails a

freezer by taking the time to plan your upgrade? You should your team should ask do we want to upgrade income incrementally from 3 to 240 241 or do you want to just rip the Band-Aid off and go straight to 5 to 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. We can just do it. Our operator get home. I knew was give me long enough that it made sense to work incrementally so that we can stay motivated if we tried to go straight to 5 to and it taken more than a year. It was going to be kind of difficult to

bring it kind of like we did it and then we did it again and again and again, so they were all happy about that. You should you can all just also consider that if you want to do the the two branches thing or if you want to have a dual booting CI this can the diluting see I can really help you pay that down up front so that you can make you make her future operates easier. If you do the long-running branch, sometimes I can be really difficult to keep up with features that are going in to the master. Are you can also make your upgrades Easier by fixing

deprecation warnings early instead of ignoring them to take care of for 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 on so you fix them. If you ever work at the earliest method change application, you're basically just can't boot if you have that deprecation warning, so you want to fix that before you ask I get a kiss the point where you just have to wait for those to be fixed because if you have if you fix them that you can see all of a failure to know how far behind you

are. Once you upgrade it to the most recent version make a plan for future upgrades. How often is your team willing to upgrade Rosen the future. Are you interested in testing new releases of rails in the beta or release candidate phase this can help make upgrade smoother. If everyone else because you can tell us on the route seeing what was hard and we can fix it before you release that version. If you can't run real natural production, can you invest into dual boot eci's then you can test rounds 5 to unrealistic simultaneously

if you invested in upgrading it make sense to invest in tooling for the future so that you can stay out of upgrade debt. Two considerations that you should take when upgrading things that you will regret I should not do. 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. Tell me where you're likely to regret in. The future is fortinbras. Don't do this. The choice of foreground and deviate from upstream was the single most expensive choice. We made it get Hub in regards to our application. This

had a compounding effect on the state of their code base that made our upgrade take that are free from 2 to 5. Take 7 years. If you absolutely must work rails at you should try to at least track the Austrian version as closely as possible and only back for bug fixes or features that you need. If you add features that you never intend to Upstream to Ralph your fork is going to 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 do something like Wells long-term support because they'll maintain the fort for you and ensure that the security patch is correct. If you fall behind on Ray and upgrading your own patches, you may do it wrong and leaving insecure and point in general. The best way to do any security patch is to rely on Rails upstream and sharing your application tracks the most recent version of rails can reduce any surprises when you upgrade for that security patch. Are also using old unsupported gems your upgrade any more difficult because you have to

replace each of those dependencies before you can finish your upgrade and sure that you upgrade your dependencies often to keep in line with rails requirements. This will also prevent you from ending up using a gem that gets abandoned by its mean here because rails isn't going to require a gem that is no longer maintained. You may also regret using rails private apis. Nrel's private apis are code that is purposely undocumented or under the private namespace. We reserve the right to change his 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 deprecated them if you if we ever intend to change or remove them. Do all 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, you're feeling a little better 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 10 years that no longer work at your company. I did I apologize to all of you. But I want you to know that you can do it. I have faith in you you may be thinking okay while I lean like you're on the rails for team and you work again, and I'm not capable of doing the upgrade. It's too hard. We just don't have the talent or the time. Show me a lot of people is true and it's not because I want to Pat myself on the back and have you all clap for me. What is because I want you to know that you can do this before the rails 325 to upgrade. I had

never done a major multi version upgrade before and upload it to production. If I can do it. You can do it or not smarter than you are not better than you. I just might be able to crazier than you. But you can totally do it. It's not going to be easy, especially if you've taken on cumulative costs that we looked at earlier. Operating 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 down incrementally overtime start with that weird class that you don't know what it does or is that uses a private rails

API remover document identify if you and your team incrementally pay down debt the debt that you've incurred blood bet the over the debt incurred that I'll eventually be possible and complete. It is also important to remember that you're not alone many before you have done an upgraded many after you will do an upgrade. Find others doing upgrades at the same time. We're supposed to have done in the past and lean on them for support. I knew that stuff. I had just

finished their own heart upgrade. And so I had them to ask like hay is it ever going to be over or advice how to continue? And last week remember that the payoff is worth it. Upgrades take a long time and they're really difficult but being afraid of upgrading isn't going to make it go away. When you upgrade your application. It'll eventually be in a better place in addition to improve security easier hiring and we're mannsville dependencies doing the hard work of upgrading will give you an approved apis major version upgrade allow us to rethink our previous

features and rails worked and redesign them and rework them so we can approve them for you an example of an improved API and rl6 is the handling for multiple databases before well sticks and very hard on yourself, but I'm real sick Smith 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. Appraised new version of rails also improve security security upgrades being easier. If you're not behind

rails also add the new security features to protect your applications and your users from Bad actors in Reynolds, V introduced performance at 5 to introduce his secrets and rl6 is shipping with improved security around potentially dangerous are all methods. These features will help keep your applications safe and secure since these are security features and they're not going to deleted patches. The only way to get them is to be on a new version of rails. And although Roastery I was played by performance issues newer versions of rails have focused on better

performance. The real team is always looking for areas to make rails faster and all environments and rl6 is shipping with a memory leak fix for new Learning and Development and faster after support notifications. And other stuff that I cannot remember. I'll bring World also gives you access to new libraries real sticks of shipping with new parts of the framework like action text active action mailbox, one of the mailboxes and light work by upgrading you can rely on great new features and rails without having to build your own infrastructure truly in your application

and I'll deal World your application would contain only tell that pertains to your product and her 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 and under framework begins crystal clear. and lastly of Greater application gives you a chance to contribute Upstream. It's really difficult to fix bugs add features and influence. The future of Ralph's were an old version is not a requirement to contribute if your on

Rouse Master, but it definitely helps open doors that are otherwise closed in 2004 and many times since Frameworks are extracted. We build rail from our existing needs. But if those knees are set back and rails 2 3, it's hard to make keys for extraction that our application requires. All of these are good reasons to upgrade with 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 wasn't like you have a good influence the future of rails forget how this is the biggest and most important reason to upgrade BIOS command features fixing

bugs and supporting Rouses future. We support our future as well. When I look back at when I started the 3225 to upgrade the thought of being on a modern version of rails and actively contributing Upstream felt like an achievable Fairy Tail. 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. I love that still questionable. But now regularly contributing to rails and supporting the future of Rouses gives present and future State since upgrading roles get of engine years is 10 / 75 pull request

performance fix bugs and add major functionality to rails before we upgraded we were often forced monkey patch or work around bugs and overly complex ways using rounds 5 to has allowed us to not just contribute Upstream, but to make choices and 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 Improvement. We're extracting major functionality from GitHub. We don't have time for technical details, but we've extracted are handling for multiple databases and Route 6. We've used

our knowledge and expertise on an easy-to-use robust a new API for defining establishing and switching connections between databases in your application. We did this extraction not just because it benefits rails because it allows us to reduce complex. in our own application our goal is to never fall behind ever again. We're investing in our application in in rails by doing continuous upgrade every single week. We bump our routes gym and run all of our tests against the new version that was fine regression sand rails quickly and fix them before we released that version it also lets us

tests all get his coat and round 5 2 and 6 to simultaneous simultaneously. Take me to the hard work of upgrading major does new process means that we won't fall behind again because our upgrades are easy and we're doing them as well as changes instead of many years later because of this we're confident that rl6 is performance stable and resilient. Continue with upgrades and are contributions to rails are evidence of for the first time you get his history. We're not just using rails or simply building a rails application for the first time in the future of rails

Works tracking code from GitHub building new features in the rails that will help you scale your application and giving back to open source to support rails for the long haul. It makes good sense for us to do this. Not only do we get back to the community, but it helps us keep our application focus on our project product. We can reduce complexity and improve Brazilians all while contributing to the future of route. I could have 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 Realms framework

and we have the influence expertise and application to help push rails forward. Upgrading roles has a huge investment. It wasn't cheap, but it was so worth it. I'll breeding grounds opens up a ton of possibilities for the future and we have a Bright House ahead of us. We're building features faster with more confident. Our code base is stable or improving the scalability of rails and we're giving back to the open source community at a minimum rails and the decisions that we made to building up our application to building a browse to building up our

community. Upgrading rails gave us the freedom and flexibility that we didn't have before empowers our Engineers to build more and build better. In 2007 get up was born and 11 years later. We're finally tracking Master. It took seven years in the day. The 300 upgrade was started to the day the 5 to 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 and rails and how our community thrives I get home will continue to invest in the future of rails because our kids and our community because we have to because we

need to and because we want to Will 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. I think we have three minutes or a minute left part exact clock so I can take probably one or two questions. The question was how is the engineering culture change now that we're talking Master with waiting for pull request in the rails and stuff. So first we have more privileged than the average company because we have two people from the rails for team working on our team. So and no one is going to for crafts without coming

through us first because the window well But you know, I think most of what has done as it's given an opportunity to contribute to her that I didn't have before and it's changing our culture in that everyone is like, oh my God, I can contribute to Ralph's now. This is before we like I guess I can backwards on weird stuff to this work and doesn't feel as good. And so I think they haven't having that access to do even if they don't even if someone doesn't

have the time I've seen and ears make time for it because they're excited about it. And we are team is totally unaware that there to help them do that. So if any other person here aren't aware of that will help you could you beat up stranger else that's a part of our job and we push really hard for that because it benefits us and it benefits get home any benefits or else it's a win-win-win situation. I think I have to be done.

Cackle comments for the website

Buy this talk

Access to the talk “RailsConf 2019 - The Past, Present, and Future of Rails at GitHub by Eileen M Uchitelle”
Available
In cart
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “RailsConf 2019”
Available
In cart
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “IT & Technology”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
166
app store, apps, development, google play, mobile, soft

Similar talks

Joel Quenneville
Developer at thoughtbot, inc.
+ 1 speaker
Rachel Mathew
Software Developer at thoughtbot
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free
Lyle Mullican
Founder at Blue Peak Software LLC
Available
In cart
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “RailsConf 2019 - The Past, Present, and Future of Rails at GitHub by Eileen M Uchitelle”
Available
In cart
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
577 conferences
23231 speakers
8691 hours of content