A good warning sign for companies that only have their codebase at Github which seem more common to me nowdays. If you run your own server at least you can like physicaly restrict the access to local network only.
You would if you designed your build process that way. I think it's a good idea to eliminate all third party build-time dependencies. In practice this means keeping a Git clone of everything to use for official builds, or anything that can't risk a third-party being unavailable when you need it most.
I mean, having a proper local master backup is a great idea, but you could survive without it in a case like this. Just set up a new repository somewhere everyone can get to it and have everyone push to it.
https://github.com/toolmantim/bananajour is pretty nifty.
I've worked at places with enormous enterprisey SVN checkouts that might take an hour or two to slowly download off the internet even though the developer at the next desk may have the exact same bunch of bits available without having to go all the way out to the internet and back. Just solving that problem with better Git tooling could mean a better experience than the current re-centralised decentralised version control...
Our internal source control server is more reliable than our local shared ethernet with cable backup combined with the reliability of github.
We've had 43 minutes (scheduled and unscheduled combined) downtime in the last 11 years across three VCS technologies hosting internally.
If it was github and remote, we're talking about 7 days of downtime in the last 2 years alone.
We're definitely in charge and it has consumed virtually no admin effort in that time. The VCS server currently has an uptime of 3 years, 5 days, 20 hours and 38 minutes. It's also shifting 10mbit peaking at 200mbits pretty much all day every day 24/7/365.
(CentOS 6, SVN, HP DL380 for ref)
To be fair we haven't patched that box's kernel since it was rebooted but we really don't have to bounce kit very often. Most updates are handled through service restarts. Only updates that are an attack vector internally are actually applied too.
As for the usual problems of power, we have battery and generator backed support. Redundant NICs on two VLANs and redundant power supplies on two feeds and a RAID array obviously.
We also have a large memcache deployment that hasn't been restarted in that timescale as well. Even the memcache processes are that old. Works wonderfully.
Also CentOS is pretty damn stable.
If this was public facing it would be a slightly different story as we'd be patching the kernel too.
(1): by uptime I mean time up during office hours under the assumption that dev workstations can run. There's no point in measuring uptime during a power-outage...
The problem is not having a third-party host, it's having no redundancy.
We use this, in our capistrano tasks :
set :repository, ( ENV[ 'FALLBACK' ] ? fallback_url : github_url )
This post does not specify what happen on a `git fetch all`. I suppose it takes the first one, and you have to specify other remote entries if you want to pinpoint the remote repos to use ?
Note that the deploy I mention will do a fetch, so this solution does not replace the fallback variable.
Past that I've not used it that often outside of having a cheap cluster solution in a way. Try it out and let me know!
We do not use github only for issues and PRs, though, but also with repos hooks : pushing to a branch trigger a build on our CI, which then deploy our staging env if successful.
Of course, we could do as well with git hooks and writing code to do the web push. I just can't see any reason to migrate to that.
I guess I'll have to look into what ElasticBeanstalk is doing.
They're using git, don't they? Obviously you miss the web interface to issues, pull requests, etc; but if you don't have git repositories distributed in your own infrastructure you're doing it wrong.
I don't think there are many companies who have the depth of info security knowledge that Github can draw upon. You might believe that running your own server and locking it down to your local network (as best your team can do that) is better, but I'd rather trust Github even if that means my code is available online. While the chance of being victim to a non-specific attack is far higher (Github is a much bigger target; I'm affected if they're attacked), the chance of someone targeting my code and actually getting it are far, far lower because Github is better at making things secure than I am, and they have people who are paid to make sure things stay that way.
A policy of only having your code on Github has it's flaws but making sure it's secure isn't one of them.
No, it doesn't. Why should it?
That's true and I believe in that as well. However, GitHub also poses a much larger attack surface than any single company and it's safe to assume that once someone is in, they're going to get _everything_. Apart of that, you're also vulnerable to having GitHub disgruntled employees accessing your data, and the inherent vulnerability in having a remotely accessible repo in the first place.
And our Internal security team (BT Security) was bad news if you where investigated - they have a ferocious reputation
http://www.wired.com/2010/09/google-spy/
>Google acknowledged Wednesday that two employees have been terminated after being caught in separate incidents allegedly spying on user e-mails and chats.
>David Barksdale, 27, was fired in July after he reportedly accessed the communications of at least four minors with Google accounts, spying on Google Voice call logs, chat transcripts and contact lists
>In the case of one 15-year-old boy Barksdale met through a technology group in Seattle, Washington, he allegedly tapped into the boy’s Google Voice call logs after the boy refused to tell him the name of his new girlfriend. Barksdale then reportedly taunted the boy with threats to call the girl.
>Barksdale also allegedly accessed contact lists and chat transcripts of account holders and, after one teen blocked him from his Gtalk buddy list, reversed the block. A source told Gawker that Barksdale’s intent didn’t appear to be to prey on minors for sexual purposes, but simply to goad them and impress them with his level of access and power.
I recall at least two vulnerabilities that GitHub was exposed to. The mass-assignment one from Rails (which they didn't fix until after they were the poster-child for it), and the cross-site one, which prompted them to use github.io.
I suspect their security teams are better now but you're still taking it on faith. By using 3rd-party services, you are increasing your exposure, not diminishing it. Someone who wants to attack you specifically will do so regardless.