September 11, 2015

Keep Delivering for Success with Git in the Enterprise

What's New
Continuous Delivery
Git at Scale

(Part 3 of a 7­-part series)

Throughout this series of posts, we are reviewing some of the challenges faced when adopting Git in the enterprise space, and presenting tips and best practices for successfully managing the task. Today’s entry examines the need for integration and testing while avoiding excessive server loads.

Continuous Delivery

Whatever workflows your contributors favor or type of content they create, the final products ultimately have to be integrated and tested with as much automation as possible on the road to continuous delivery. The architecture of Git can make this automation a heavy load on build systems, so planning is necessary to get reasonable performance from continuous delivery systems.

A common best practice for continuous delivery is to run builds and tests against a fresh copy of all your files. But in the enterprise, this step can easily overload servers when using Git, for two reasons. First, like most distributed version control systems, Git brings down all revisions by default during a clone operation. And second, Git has no support for narrow cloning (bringing down only the necessary files instead of everything). In short, when you clone with Git you get every revision of every file by default.

These issues typically aren’t problems for open­-source and other small­- to medium­-size projects, but they can become fatal obstacles for larger enterprise projects. The sheer volume of merge operations when dealing with a large number of development branches can create a similar stumbling block. Git encourages developers to branch for each task or feature, but keeping all that work in sync in both directions can be tricky with large teams working with lots of files.

Continuous Delivery Best Practices

  • Use shallow clones to get just head revisions, and prefer a Git management solution with support for narrow clones; both will greatly ease server load.
  • Choose the right build cycle times/events for your projects; building every hour or day (instead of on every commit) may be necessary when using Git.
  • Automate code merging as much and as frequently as possible to catch integration issues before they logjam the flow of code.

Keep Reading

The previous posts in this series are available here and here. In our next installment, we’ll tackle the critical issue of reliability and disaster recovery. For the complete set of Git in the Enterprise tips and best practices, download our free eBook here.