Again? This is like the fourth time GitHub went down. Last time this happened was almost a week ago. [0]
Seriously, just consider self-hosting [1] rather than 'centralizing everything' [2]
[0] https://news.ycombinator.com/item?id=23604944
Again? This is like the fourth time GitHub went down. Last time this happened was almost a week ago. [0]
Seriously, just consider self-hosting [1] rather than 'centralizing everything' [2]
[0] https://news.ycombinator.com/item?id=23604944
Or live with it and list GitHub downtimes as one of your business risks.
Absolutely, but if downtimes go up, then it starts making sense distrusting that provider and thinking about alternatives.
How much downtime could it get? They might redesign the homepage a few times and break it accidentally, then it's done. They're not gonna redesign it again and again every week forever.
Are you sure about that?
You under-appreciate how enterprise software development tends to go.. there's always new "features" to be had, KPIs to measure and no time to tackle tech debt...
> "Or live with it..."
Try working within a deadline, no engineer worth their salt would ever take this advice.
self hosting is definitely a viable solution.
An engineer can surely plan enough leeway into their deadlines that few hours of github outage doesn't scupper their project
Yes, the question is probably will management allow that?
Hosting your own does not guarantee you 100% uptime. It just means someone less expert than the GitHub folks will be responsible for bringing things back online. It also costs you time and effort, which is a problem if you're on a deadline.
Same goes for the question of where to host it physically. It seems unlikely your physical server will have better uptime than a virtual server in the cloud.
It's about control, not anything else.
If all I need is a git repo, with some tools. Why pay someone to mess it up, when I can mess it up for free?
The moment you place it in someone else's work queue you are tied to them... and they might not care about your projects deadlines. Just like github.
> Why pay someone to mess it up, when I can mess it up for free?
Because it isn't free. Your time is a huge cost.
A senior dev who spends even 10 hrs on standing up a git server has blown through years' worth of GitHub costs, and that's assuming you're even actually using the paid service.
Factor in the extreme security requirements of a code server, including needing to update dependencies daily, and you're spending far more time self-hosting with riskier results.
To add to this, and at the risk of restating my earlier points: even if you get it working, it still probably won't be as reliable as a provider like GitHub.
Keeping it secure is no small thing, especially if you want to permit access from arbitrary IPs on the Internet (rather than using a VPN, say). GitHub does this, and presumably they have solutions in place for everything from intrusion-detection to DDoS protection.
GitHub employs people to take care of server failover and data backups. You could spend your own time building your own solutions here, but they're unlikely to be as good as GitHub's. Your solution is guaranteed to be less well tested.
And that's assuming you even have a server room in the first place. You could run your own Git in the cloud, of course, but you're not really 'running your own' if you do that. GitHub take care of the server question (apparently they use a physical-server provider called Carpathia [0]), and because git always needs to be available but is only used rarely, the amount they charge you is probably less than the cost of running a dedicated server for the purpose.
And all that is assuming that a self-hosted GitLab is just as good as GitHub from the developer's point of view. It may or may not really matter, but GitHub is probably the more polished and feature-rich service.
Building a competitor to GitHub is possible, but not trivial, see SourceHut. (We've been talking about GitHub, but of course they're not the only Git provider.)
I can see only a few situations where it makes good sense to run your own Git/GitLab:
1. Your Internet connection is slow and/or unreliable
2. There are extraordinary safety/security concerns associated with your source-code (military avionics code, say) so you want to run Git in an isolated network (no Internet connectivity at all)
3. Related to point 2: You don't want your organisation's data to reside in the USA. (To my knowledge GitHub don't offer any choice about this, but I could be mistaken.)
For the average developer though, I don't see much upside. Having more control isn't a compelling advantage, it's another way of saying you have more obligations.
[0] https://github.com/holman/ama/issues/553
What about the business risk of someone tripping on your git server power cable?
You can plug it back in yourself.
I set up a self hosted Gitlab where on-prem was a requirement and it's surprisingly easy. Obviously another service that needs to be maintained and updated but as code repositories and connected services are a crucial part of infrastructure it makes sense to have control over that.
Not the biggest fan of Gitlabs UI but I got used to it quickly.
> Not the biggest fan of Gitlabs UI but I got used to it quickly.
It gets more attractive now that GitHub starts changing theirs. Might as well adapt to GitLab now.
You can self host github or bitbucket as well, but it does get expensive.
There's always https://gitea.io, the self-hosted Git server project that powers https://codeberg.org/
I find it a bit surprising that it is still a headline, sure it is a huge service used by many. Though as you write its not the first time this year. But apparently still people use a single service as their 'origin'.