The video is nice, but not particularly actionable - if you’ve used GitHub Enterprise within the last year, or browsed GitHub’s website marketing, you’ve probab

The video is nice, but not particularly actionable - if you’ve used GitHub Enterprise within the last year, or browsed GitHub’s website marketing, you’ve probably seen many of these features already. https://gh.io/how-we-build-github https://gh.io/how-we-build-github is linked to from the description and has a few more interesting articles and case studies. While they don’t often go into detail, you’ll pick up some tips and best practices on how to best use GitHub at a larger org. If there’s a limitation, it’s that for enterprises, a lot of these features have big price tags attached by design, and some of the big features, like code spaces and CI runner VPCs can be done through local .vscode project files and self-hosted runners for cost savings. Unfortunately, there’s literally no way to replace GitHub’s secret scanning on-push given that you can make commits so many different ways and only GitHub can scan them all. And GitHub’s pricing for their security package reflects this, at least at an enterprise level. And let’s not talk about storage costs or other ways they get you with consumption billing. Caching speeds up your CI but you end up paying for it in bandwidth and storage costs, likewise talking to GitHub releases was free, iirc, but downloading a published package had a bandwidth charge, I’m forgetting the details but GitHub billing is full of weird inconsistencies due in part to how GitHub worked historically, but also because newer things are designed on and for the cloud, and the cloud’s billing model… Until they added a page for it, there were scripts you could run to see which repos took up the most space, because yup, you can get billed for that too. There’s a small part of me that misses the simplicity of self-hosted GitHub Enterprise in that you could quickly navigate to other enterprise projects (last I checked, labels were still broken in GitHub Enterprise for listing internal projects), maybe wrap it in a cloud proxy and add your own secrets scanning, or link your self-hosted GitHub to your self-hosted Jira. (Note: I absolutely prefer the cloud-hosted versions, but it was possible to tune the performance of local versions in a way that it isn’t possible to do so in the cloud. I never worked for a company that bothered to tune them, but it /was/ possible. And probably cheaper.) I probably shouldn’t ask why GitHub repo and org settings can’t be managed through GitOps in 2023, or why GitHub defaults to using HTML and web pages in 2023 instead of making API-first a standard across all their features. The number of times I’ve thought to myself that it should be easy to do X via the API only to discover that the only way to do X automatically is to use Puppeteer and Chrome to screen scrape… the worst offender at one point, besides Projects and other new features, was OAuth app management and approval. So many GitHub features are still designed web-first and GitOps or API never… or at least not yet. My favourite is when doing something requires combining both the old REST API and new GraphQL APIs, because yes, that is also sometimes a thing.