December 8, 2015
Reliability for Git in the Enterprise
Git at Scale
Throughout this series of posts, we are examining some of the challenges faced when adopting Git in the enterprise space, and presenting tips and best practices for successfully managing the task. In today’s entry, we’ll look at the fundamental need for reliability and recommend best practices for disaster recovery.
No matter how well a tool does a job, it’s not useful when it’s not working. This is especially true in the enterprise, which often runs around the clock around the world. Git was built largely with the simple file system in mind, and most Git management solutions are built directly on top of basic Git. So achieving enterprise goals for disaster recovery and high availability can be challenging.
Most Git management solutions offer services such as backups and snapshots, which are a good first line of defense. Some offer higher availability through standby VMs with various means to mirror changes between file systems and/or swap out different file storage as needed. But if what you need is dial-a-load scalability with high availability, your list of options narrows considerably.
Although it may appear to be simple to clone another copy of a repository for safety, you’ll be cloning the whole repository with Git. This approach is fine for small or even medium-size projects, but big projects consume bandwidth, disks, and time. If your content is measured in anything beyond megabytes, you need to dig carefully into the details of reliability with your Git management solution.
Reliability Best Practices
The previous posts in this series are GitSwarm: Your Questions Answered, Narrow Cloning with GitSwarm, and GitSwarm + Helix: Unity through Diversity. In our next installment, we’ll tackle the critical issue of security. For the complete series of Git in the Enterprise tips and best practices, download our free eBook.