GitHub running off the main branch is fascinating, and initially sounds mad, but makes so much sense. Assuming they have very high test coverage, running against mainline Rails isn't really any different to having the fork they had before, but they have more influence on future development.<p>It must also be a massive boon for the Rails ecosystem to have such a large property running off the head.<p>Doesn't anyone know of any Django shops that do the same, running off mainline?
I built my startup 4 years ago with a combination of react + aws + gatsby + hasura. I thought this would be great for performance and scale. Fast forward to today, I spend at least 2x as much time to code a feature than if I had just stuck with a simple rails stack, and the scale I imagined never happened. Now rebuilding everything with rails so I can ship faster and focus on growing the product, not making engineering prowesses.
I absolutely love Rails. I'll always remember back in 2010 catching the train to Waterloo station in London and seeing a huge sign overlooking the train tracks that read something like "We Need Rails Developers".<p>Rails was such a huge part of my professional career.<p>Now, 13 years later and I'm deep in the JavaScript ecosystem and have been for 8 years.<p>The most exciting thing to come out of this ecosystem recently is RedwoodJS, because it takes a lot of inspiration from Rails.
I like GitHub, fwiw. I am not someone who requires everything to be perfect, and I've learned to be tolerant of our human reality, where imperfection is the norm.<p>But GitHub is not a great Web app. It is frequently/constantly out of sync with the latest data/status. You quickly develop the habit of manually refreshing the page every time you are preparing to do anything with a PR, and that's not something that should be necessary these days.<p>It surprises me to see a loud and proud blog post detailing GitHub's process of staying so relentlessly up to date with the latest and greatest version of Rails: the app is not properly responsive, for whatever reason, and to a degree that would not be tolerated where I have worked. I would rather read about how they are trying to fix this issue.
And as I have said before but worth repeating again, Rails is perhaps the only open source framework that is being battle tested in development at scale. It may not be the fastest ( or in fact quite slow ), but I dont think you could find similar testing being done and Deployed at the scale of Github on any other framework.<p>I wonder if Eileen Uchitelle will bring this practice to Shopify as well? Edit: It seems [1] Shopify is also running on latest Ruby and Rails version as well.<p>[1] <a href="https://news.ycombinator.com/item?id=35481352" rel="nofollow">https://news.ycombinator.com/item?id=35481352</a>
It is so nice to have the latest releases of both Ruby and Rails run in production as soon as they are released. Huge for indie developers and small teams that use Rails.
Kudos to Shopify too, who are working on improving Ruby tooling a lot recently.
Exciting time to be a Rails dev.
Github is one of the few webapps where I can feel <i>daily</i> that the framework used isn't enough. So many things get out of sync/not up to date, which are fixed by refreshing the page.
> Instead of telling your team you found something in Rails that will be fixed in the next release, you can work on something in Rails and see it the following week!<p>That's awesome. Not only fixing it for your team but the entire rails world.
We are also running on Rails - and loving it, too.<p>However, incorporating this methodology into our workflow would be both a lot of work to set up and also a lot of work to keep running.<p>There certainly is a size threshold under which this is clearly an overkill and we are under that threshold.<p>Yet, if this could be turned into a product, a clean integration, a command I need to run... would definitely use it (and pay for it).
Going a bit of topic, Arch Linux does mostly the same, and thanks to it all of its users are direct testers/reporters of unpatched projects, with the exception of a few minor patches related to chore in projects that don't allow to customize it (mostly paths). I guess that this has probably improved the overall health of Linux beyond Arch itself during the last 2 decades for similar reasons to the ones provided in this article.
I must be the only person on Hacker News who dislike Ruby.<p>It simply has too much magic and doesn't offer enough abilities (unlike Elixir or any Scheme variant) to justify the dynamic type nature.<p>Go and Rust are perfect for me (and maybe Zig?). They covered everything I need.
I've been using Rails and GitHub since the first 2.x days. I have been expecting an announcement that they are switching to .NET since Microsoft bought them. I'm guessing it's too big of a bite, even for Microsoft, thank Ada. I love being able to point recalcitrant policy makers at my company at GitHub as an example of a top web app -- the context for which they already know very well -- being a Rails monolith.<p>I'd love to see their Gemfile.
Ruby and Rails are the single reasons why my previous startup worked out. We had a small engineering team and had to move incredibly fast. Without the magic we wouldn’t have been able to ship at insane speed. I tattooed the ruby logo on my arm as this was an absolute life changer for me. Having financial freedom now lets me spend so much time with my kids. I’ll be forever grateful.
It's been interesting looking into their "leaked" source to see how the application is architected. It's surprisingly accessible given the overall size.
I think the big lesson here is writing excellent tests and making them easy to execute makes your code easier to change fear of breaking something.<p>Unfortunately I’m fairly certain the message that will be heard is ‘We should totally change something around on the customer every week, that’s what GitHub does’
> Ultimately, if more companies treated the framework as an extension of the application, it would result in higher resilience and stability. Investment in Rails ensures your foundation will not crumble under the weight of your application. Treating it as an unimportant part of your application is a mistake and many, many leaders make this mistake<p>I really like the sentiment of this quote but that is an easy thing to say for a behemoth like GitHub.<p>I find these blog posts from google, meta, aws etc super awesome since they run and solve problems smaller companies simply don’t have. And they shape how smaller companies solve similar issue at smaller scale. But doing a setup to be practically on bleeding edge rails for example is not something every company can afford. They need LTS releases and the sorts. Still awesome that they managed to achieve this.
Good post and an interesting glimpse into the behind-the-scenes efforts that goes into maintaining Github.<p>I cannot agree with the "Should I do it too?" section. It probably works very well for an org as large and dedicated as Github, it very likely makes a lot of sense for what they do at the scale they do it at.<p>For most of us that are <i>consumers</i> of technologies and frameworks, treating the framework as an extension of an application stack, as the blog has outlined, is a terrible idea; it requires devoting time and effort towards its upkeep, and that is not our core business, nor should it be.<p>That does not, however, mean it's being treated as an unimportant part of the application stack, and implying so is judgmental. It's importance is that you need to be careful about the tech choices you make and understand what the implications will be down the line.
I wonder how much they end up having to unit test gems they use, and how much they have to maintain gem compatibility for those maintainers..<p>I have to imagine this leads to either GitHub being the defacto lead maintainers for those gems, or GitHub removing gems from their stack and writing their own code.
I'm curious what their data access layer looks like underneath that monolith. Is the Rails piece mostly now just a frontend for dozens of other services, properly owned and maintained by other teams? I don't mean to trivialize something that's obviously huge and complex as "just a frontend", but IME one of the biggest things that breaks down in a Rails monolith as it scales is heavy, direct usage of ActiveRecord. Either there's lots of DB migrations happening since there's so many different developers working on different features, which makes development with a shared DB tricky, or the scale makes DB performance problems hard to diagnose since they cut across many teams or tables in complicated ways.
Some of their points which reminded me I consider working well, also for smaller teams.<p>* Parallel builds/CI to look into the near future: current + next. When time is due current and next need to become green and the next alpha becomes future, which is allowed to fail (3 parallel tracks: current, next and future). Keeps all your build tools en par early, too, so there is less rot, and one team can concentrate on the migration while other teams aren't interrupted by that, but also for a single or only a handful of developers, you can have better change management (at the cost of the extra computing power).<p>* It feels less a monolith, if its in a dynamic language (not compiled / transpilled / linked) and in many files (there is little to build and deployments are smaller and faster). In such projects, increments are possible across multiple axis in a synchronized dance.<p>* Pipeline everything and continuously shift left. Identify the most important improvements and if they can step-break the process well, apply the earliest one coming from the developer perspective. Any such change will speed up any change after that step.<p>* Implement fast turn-around with the parts that change often so you can change them often well. Cooperate well with upstream, this is most often a key to ongoing success.<p>* Distributing traffic over multiple application servers and being able to deploy different configurations / revisions and directing part of the traffic to it is invaluable. Have your tools/systems configured well to make it easy and comfortable to do this way. Production must not feel like an all or nothing game any longer, but serves as experimental playground.
Even as a much smaller team, building Heii On-Call [0] as a lightweight alerting/monitoring/on-call rotations SaaS based on Ruby on Rails has basically been a pleasure!<p>And as the article highlights, perhaps the key reason for smooth deployments and upgrades is that the CI testing story is so, so good: RSpec [1] plus Capybara [2] for us. That means we have decently extensive tests of just about all behavior. The few small Rails and Ruby upgrades we've done have gone quite smoothly and confidently, with usually just a few non-Rails gem dependencies needing to be manually updated as well.<p>The "microservices" story is where we've pulled in the Crystal programming language [3] to great effect. After dabbling with Go and Rust, we've found that Crystal is truly a breath of fresh air. Crystal powers the parts of Heii On-Call that need to be fast and low-RAM, specifically the inbound API <a href="https://api.heiioncall.com/" rel="nofollow">https://api.heiioncall.com/</a> and the outbound HTTP(S) prober background processes. I've ported some shared utility classes from Ruby to Crystal almost completely by just copy-and-pasting ___.rb to ___.cr; porting the tests for those classes was far more onerous than porting the class code itself. (Perhaps another point of evidence toward the superiority of RoR's testing story...)<p>The front-end story is nice but just a bit weaker. Using Hotwire / Turbo successfully, but I have an open PR to fix a fairly obvious stale cache bug in Turbo [4] that has been sitting unloved for nearly a month, despite other users reporting the same issue. I'm hopeful that it will get merged in the next release, but definitely less active than the backend side.<p>For me, the key conclusion is that the excellent Ruby on Rails testing story is what enables everything to go a lot more smoothly and have such a strong foundation. I'd be curious if any GitHubbers can talk more about whether they too are using Rspec+Capybara or something else? Are there internal guidelines for test coverage?<p>[0] <a href="https://heiioncall.com/" rel="nofollow">https://heiioncall.com/</a><p>[1] <a href="https://rspec.info/" rel="nofollow">https://rspec.info/</a><p>[2] <a href="https://github.com/teamcapybara/capybara">https://github.com/teamcapybara/capybara</a><p>[3] <a href="https://crystal-lang.org/" rel="nofollow">https://crystal-lang.org/</a><p>[4] <a href="https://github.com/hotwired/turbo/pull/895">https://github.com/hotwired/turbo/pull/895</a>
This is a very interesting cautionary tail for those who recommend Rails because Github uses it. It's hard to imagine another core framework where the "best" way to use it is to dedicate an entire department to continuously working off the bleeding edge. And if you read between the lines, changes that Github needs to make are within Rails itself, and as we know there are core Ruby and Rails maintainers working at Github. This is a cautionary tale because of how much overhead Github needs to make this work. If your company has the klout to hire core Rails maintainers and the staff to be able to focus on working off the main branch of one of your framework dependencies, then go for it!<p>You should also read about Github's history with "Rails" and how challenging it was for them to make it fast enough for them and upgrade it. It's pretty interesting they got around that "challenge" by throwing a LOT more resources at it. It's interesting because this isn't usually a challenge with other major framework upgrades. It makes sense you would need this much investment given the hyper-dynamic dangers of Ruby (not just the language, but the ecosystem), making it difficult and risky to upgrade.<p>TL;DR the advice in this blog post does not seem applicable to most companies.
This make so much sense, I think every company should update deps frequently and Dependabot and other services like that can help with that. It probably would be too costly to attempt what GH is doing for smaller orgs.
Absolutely love this approach and I think it makes a ton of sense for an open source focused company - however I haven't seen this approach in any company I've worked for in 15 years (where I have helped with most of the Rails upgrades!).<p>There's a ton of merit to being on the latest release or close to it so you can get the latest security patches easier. The diff between that and the latest `main` branch seems like it has diminishing returns for most orgs.
I've been using Codeberg, which uses Forgejo which is written in Go and is fast and light.<p>Fantastic that GitHub has managed to wrangle so many lines of code in a language I don't care very much for, but my Samsung A53's browser is snappier without it :)<p>Edit: to be fair, GitHub's has a hamburger menu that morphs to an X that I dearly miss. JK :P
> <i>Every Monday a scheduled GitHub Action workflow triggers an automated pull request, which bumps our Rails version to the latest commit on the Rails main branch for that day.</i><p>That’s a bold move to do as opposed to being end of week or weekend.
This is awesome, now I just wish they spruced up their UI with Hotwire :p How many times have you clicked the back button and found the same notifications unread?
> Every Monday a scheduled GitHub Action workflow triggers an automated pull request, which bumps our Rails version to the latest commit on the Rails main branch for that day.<p>So uploading code to a github repo makes github server execute it later on. I wonder if this would qualify for a bug bounty... /s<p>Edit: I guess not, since this is just a pull request and still requires approval before merging to main. I assume.
Another big rails application was twitter, it has been rewritten but the concept fitted well with rails.
Twitter currently uses some java framework as far as I know.
Question, does twitter still have some RoR deployed?
Every time it's pointed out that GitHub is a rails app I am reminded of one of my favorite security exploits ever<p><a href="https://news.ycombinator.com/item?id=3663197" rel="nofollow">https://news.ycombinator.com/item?id=3663197</a>