Hacker News Reader

Comment by raverbashing | Hacker News Reader

Have a local repos that mirrors the master one on GitHub periodically

Should that fail, start working on the local repos until github is back, then sync back to it

Depending on your definition of "periodically" you may lose almost as much time to syncing back than the outage would have caused without the local mirrors.

I've written scripts that do this. Any request for a repo is polled against the local repo server that makes sure it has the repo, and then quickly checks to see if the repo's out of date, caching the resulting file if the repo can be reached. If the repo can't be reached, just have the proxy deliver the old fileset. So the local repo gets updated, or at least attempts to update, with every hit against it. I had some other logic in the script to only check freshness every 10-15 minutes, so that during times when a lot of machines were pulling, they were essentially guaranteed to all get the same version.

This is certainly one of the better ways to do it - when I see a word like periodically I assume it means daily/weekly/on some sort of calendar-based schedule, which isn't necessarily the case here.

Why is the master on GitHub anyway?

If a company can't maintain their own internal tools and self-hosting servers, why does the same company think it can run reliable services for users?

Not putting the core of your business on a remote platform is disaster mitigation 101.

Why use AWS, GCE or any other virtualization provider? I suspect for some subset of companies the answer is the same.

Relying on Github is not the problem, relying on Github to be available 24/7 is. Github provides a free master node for your eventually consistent database needs, where the database is git. The eventual portion is key here.

Reply on news.ycombinator.com