GitHub Builds GitHub with GitHub [video]
youtube.com
youtube.com
Edit: I like the idea, I just wonder if its a viable solution when you have more than 1 team with engineering/product collaborating in github/gitlab on issues.
You end up having to do lots and lots of hacky things with GitHub Actions and the Projects GraphQL API to make it work the way you want it to. And granted, it’s cool you can do that. Having CI events fire for every issue created is awesome. But sometimes you fight their defaults soooo much, that just customizing Jira seems easier at times.
Don’t get me wrong, if you’re all in on GitHub, you’ll do okay with it. Especially if you write Actions to feed data in or out of it using the GitHub CLI and/or API or GitHub-script CI actions. But you’ll also probably miss Jira if you’ve used it as a power-user. Especially if you want to do advanced things with boards and cards and issues that it might not offer by default out of the box. And GitHub’s GraphQL API is powerful but also weirdly and frustratingly restrictive at times, particularly with usage and query limits. An easy SQL query for GitHub to run internally is opaque and confusing for a third-party to develop - GitHub knows what things are easy to hard to query by design but outside of GitHub you just make the API calls and hope it scales well to larger projects, or find out the hard way when it fails.
We only have one team of 5 developers.
Compared to Jira, it is not gut-wrenching terrible.
My employer's project manager left the month after I started, so I took over his overview.
I switched from Jira to GitHub Projects because I value my life as a developer.
It's not as feature rich, but that's a feature. The integration with PRs and commits is top class.
Projects can span multiple repositories, which is neat. We are mostly mono-repo, but we do have one active project using a different set of technologies.
I have one long-lived project for getting our main product ready, containing several milestones, some of which have deadlines yet to be determined, some deadlines stretching 6 months into delivery.
I use the kanban board for keeping track of what my colleagues are working on, and for measuring how much is left. I don't use the roadmap feature, because my employer has a time estimation problem right now, but it looks very neat.
I use a "tracking issue" label that just lists other issues. For example, a tracking issue for a particular customer. I really like how doing "- #123" in an issue or PR expands that into the title and an icon indicating if it was open or closed. This is just standard GitHub functionality, but it's super. Sometimes tracking issues are created from doing a customer integration test, where a failed test is converted into a task. But until they're a separate issue, they're just a bullet point in the tracking issue.
I'd like to be able to export an interactive overview of a subset of issues for customers to look at between meetings (which is possible to make with GitHub's API). But it's not strictly necessary, as screenshares / screendumps of the issue tracker is typically fine.
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.