In part two of our blog series (read Part 1) we share tips of adopting and scaling Git in the enterprise.
When considering enterprise-wide Git adoption, there are a few fundamental requirements that your strategy must address.
First: Protect Your Code
Prevent code from being accidentally or purposely deleted. A misuse of the powerful Git history rewrite command (push -f) may cause a situation where all the previous changes no longer show up in Git’s change history. Some Git solutions in the market offer features for disabling the history rewrite command altogether. However, native history rewrite capability is important and inherent in Git design, so simply blocking it is not a good approach. Rather than disabling the feature, it is much better to be able to control and log who uses it, when and how, and to provide the ability to restore history in case of mistakes or malicious acts. Having the ability to enable history rewrite for the right reasons, while still potentially maintaining the right level of auditability and compliance, is essential for any enterprise.
To avoid gaps in audit trails or loss of data integrity, every code change and command must be permanently registered and archived, creating a complete, detailed audit trail.
Large organizations also need to segregate duties and delegate tasks. This demands a truly flexible and enforceable enterprise-grade access control model. Code is an important asset, and access to it has to be consistent with IT governance and security policies, appropriate to the user’s organizational role, and easily enforceable across the entire tool chain.
Having granular permissions lets you control what users can view, create, or modify and can be used to manage access down to the individual branch level. This way administrators are able to manage both read and write permissions on a branch, project, project hierarchy, server, or even multiple-server level. Granular RBAC is also instrumental for situations where external contractors and consultants work on the same project as internal employees.
Also consider support for external user authentication and encryption. Maintaining dedicated user accounts for Git is not practical for globally distributed organizations with a large number of users and administrators. Common authentication methods, such as LDAP, PKI, and AD, should therefore be supported. Furthermore, both SSL and SSH protocols should be used with Git to encrypt all transferred data.
Second: Scale and Manage Effectively
Now, you need to strategize on how to go about scaling Git for your enterprise. Global, decentralized teams have diverse preferences for managing their code repositories and other version control systems may exist in your organization. Consequently, your new Git installation must be compatible with the other tools you may have in place.
Enterprise-ready Git solutions need to handle thousands of users, thousands of repositories, and hundreds of CI servers that work with them. It has to be possible to distribute the load across multiple Git servers in a single, connected, and centrally managed and governed deployment without having to stage isolated, siloed servers with different user accounts, projects, and permission setups. Replication is useful for backup and load-balancing purposes
and can also be used to speed up access to repositories in case of geographically distributed teams. Advanced replication features can include fine-grained control allowing a choice of what to replicate, how to map repository names, when to trigger sync programmatically, and more. It is essential to synchronize access rights across all replicated servers so that the same access control and governance rules apply.
The model also needs to work across globally distributed sites and support thousands of code project members. Managing such environments requires performing a broad set of administrative tasks such as creating and managing projects, configuring multiple development tools for the individual project needs, predefining tool sets, managing users’ permissions consistently across all tools, adding and removing users to and from projects quickly, and performing other advanced administrative tasks. Scalable administration models should include centralized user management capabilities and enable full visibility of all user activities across all projects and environments according to the administrator’s scope of responsibilities. Solutions that offer self-service capabilities can help offload a substantial amount of maintenance and support work from IT.
Understanding that the administration approaches in Git and Subversion are radically different highlights the value of a solid, unified administration model that makes the coexistence of Git and Subversion possible in diverse environments without skyrocketing operational costs. A scalable, economical administration model must also provide support for hundreds of simultaneous projects across thousands of Git and SVN repositories.
The choice of SCM technology to enable a world-class development infrastructure backbone is a critical business decision. It affects the long-term ability of an organization to succeed in a highly competitive business climate, enabling it to deliver high-quality software quickly and consistently. While engineering preferences and costs are important decision factors, they alone should not fully define a company’s future SCM strategy. The decision of your enterprise to adopt Git as a corporate SCM standard is not merely a technical concern. In order to effectively address the challenges of Git adoption, organizations should set the bar high by handling Git as a strategic investment and as an intelligent, active infrastructure component that improves overall business performance. While many Git solutions claim readiness for enterprise deployments, their claims should be carefully evaluated against the fundamental enterprise requirements of security, governance, compliance, and scalability.
To learn more about Git Strategies, visit our Enterprise SCM Solutions Page.