CollabNet recently published a new solution brief “Enterprise Git Adoption with CollabNet TeamForge®“. It discusses issues and common roadblocks of enterprise Git adoption and gives practical recommendations for overcoming them. The writing was prompted multiple requests from many of our customers, who want to make Git into their corporate standard. Interestingly, after talking to numerous large development organizations, we found that most of them have the exact same concerns regarding Git adoption:
Insufficient native access and audit controls in Git
Git was designed for the needs of open source projects, specifically Linux. It can reliably track who authored a change and who can add changes to a repository. While sufficient for most open source projects, this design consideration left out many of the inherent security controls of centralized version control tools, such as Subversion (SVN), which is currently used by the enterprise. This realization often comes as a shock to security and compliance officers in large companies once they discover the risks associated with migration from centralized legacy SCM to Git.
Loss of a “true” canonical repository
Limiting write access at the repository level creates an inherent motivation for developers to create more copies of the repositories (the concept known as “forking”). When users with “read only” access to a repository need to make changes to the code, they have to mirror or “fork” the existing repository to a new one. This not only explodes the disk space requirements and associated infrastructure costs but also causes intellectual property protection concerns. Once mirrored, each “clone” of the original repository has new access controls outside thepurview of the canonical repository. This opens unexpected opportunities for intellectual property leakage through many different vectors that were never considered.
Heterogeneity of modern enterprise development infrastructure
As long as hybrid SCM is still the norm, there is a need to manage Git and SVN simultaneously—not only within the enterprise but also at the individual project level. However, most Git solutions in the market today ignore this need completely and do not provide any management or governance for anything except Git itself. As a result, organizations often experience difficulties articulating their SVN/Git infrastructure coexistence strategy or face an “all or nothing” migration dilemma.
Avoiding disruption of existing business processes
Large companies are very sensitive to “deregulation” permitted by Git’s powerful branching capabilities as it potentially may cause a lot of changes in the company’s existing software delivery lifecycle management processes, causing disruption to automated integration, build, and delivery infrastructure investments. These concerns are legitimate, and stakeholders across the organizations need to have a means to preserve existing investments and replicating the company’s current business processes.
Need to maintain highly distributed, federated repositories
While the use of a central master repository (also referred to as a “golden,” “canonical,” or “blessed” repository) is easier to manage, Git does not mandate this approach. For the enterprise, however, federated deployments pose a serious risk of intellectual property or data loss. With dozens or hundreds of servers, it becomes challenging to locate code or enforce strategies for backup, disaster recovery, or failover.
If you are interested in Git but have any of the above concerns, you should read our solution brief!
We are also holding a series of educational webinars on 3/18, so you can also learn more about Git and CollabNet Enterprise Git solution by attending one of them in your time zone.
Git Webinar 3/18 Registration Pages:
UK (London): Register
United States (East Coast): Register
United States (West Coast): Register
See you at the webinar!