Why You Should Move To Offsite Source Control
Bear Giles | October 27, 2015A nightmare came up in a casual conversation at work: another group that had been an acquired business but not yet fully integrated into the corporate ecosystem had come into work on a Monday a while back and discovered that all of their computers had been stolen over the weekend. This included their subversion server. All of their source code was lost.
Fortunately one employee had checked out the latest code on his personal laptop on Friday and they were able to restore from that. It would have been disastrous if nobody had code on their personal gear. (I should point out that it is often against corporate policy for developers to have copies of the software to work on at home. This shows why it may be better to encourage developers to keep copies on encrypted disks as a form of ad hoc distributed backups.)
Source code repositories are often sitting on a spare computer somewhere. Sometimes it’s in a locked room, sometimes not. Locked rooms might slow down burglars but they won’t stop fires, flooding, etc. In theory you can create backups AND make off-site copies AND periodically restore the system from backups to ensure your process is solid but in practice if you ever need to put your emergency plans into action you’ll have wished you spent a few bucks earlier to make the problem go away.
There are two broad solutions:
First, set up your own server at a hosting company. You can probably still find colocation and hosting businesses that will lease you a real or virtual server but it will probably be easier to get an AWS micro instance. Install subversion or git and you have a working off-site repository. This gives you the most control but you’ll still need to manage the system – perform backups, periodically check for software updates, etc.
Second, hire someone else to do it. Get a private repository at GitHub or one of the other sites that provide low-cost repositories. The lawyers might grumble but, realistically, few of us write code that’s intrinsically valuable – it’s only valuable as part of the business’s ecosystem. There’s still the risk that the third-party source repository could go down or go out of business but that risk is easy to mitigate.
Something that is not a solution is to bury your head in the sand and pretend it will never happen to you. Even if you avoid theft, fires, flooding, angry ex-employees, etc., you have to recognize the real risk that computer hardware fails fairly often. I’ve had a motherboard and a couple hard drives fail at home despite being on surge protectors and UPSes – they’re only engineered to last the normal replacement interval for consumer computers and things like source code repositories and databases tend to be on systems that run 24/7 and are largely forgotten until the hardware breaks.
(This is “foreshadowing” – another essay in my queue is an exploration of whether I should put my personal databases into the AWS cloud. It has similar questions.)