Having a plan for adopting Git for your enterprise can lead to great results
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, it is not enough to only evaluate the SCM needs of your organization. The strategy should view Git as a vital part of the application lifecycle management (ALM) platform. Most Git solutions today have both SCM and ALM capabilities and claim readiness for enterprise-scale Git deployment. There are a few fundamental requirements that your strategy must address to make Git a viable SCM choice for a modern enterprise.
The first of this is the face that enterprise software organizations need to prevent code, branches, and repositories from being accidentally or purposely deleted by using a powerful Git history rewrite command (push -f). History rewrite 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. Even when history rewrite is disabled, users can still remove branches in Git without keeping any history. Rather than disabling the powerful rewrite history feature, it is much better to control who uses it, when they use it, and how it is used and to provide the ability to restore history in case of mistakes. Supervising administrators need to retain the ability to correct errors on behalf of others and to undo 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 have a need to segregate duties and delegate tasks. This makes the need for a truly flexible and enforceable access control model vital to the enterprise. Code is an important asset, and access to it has to be consistent, appropriate to the organizational role, and easily enforceable across the entire tool chain. Roles and access permissions need to be customizable in a flexible manner and should apply to the entire developer tool chain (code, trackers, reviews, wikis, etc.).
Having granular permissions let 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 control both read and write permissions and have powerful, fine-grained control over permissions on a branch, project, project hierarchy, server, or even multiple-server level.
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.
Now you need to consider how to go about scaling Git for your enterprise. Global, decentralized teams have diverse preferences for managing their code repositories. No organization would willingly accept “rip and replace” projects when this approach can be avoided. Regardless of engineer preferences, your Git solution must be compatible with the other tools your organization 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. No solution can handle the entire load of human and CI users polling for updates on a single server. It has to be possible to distribute 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.
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 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.
Understanding that the administration approaches in Git and Subversion are radically different increases 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, hybrid-friendly, economical administration model must also provide support for hundreds of simultaneous projects across thousands of Git and SVN repositories.
The distributed nature of Git does not remove the need for managed replication. Replication is not only useful for backup and load-balancing purposes—it 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, including the ability to remove a repository from a replica.
So with all this in mind, you need to make sure you keep a focus on code quality and code review. Code reviews are often a bottleneck in the release pipeline. Why waste valuable developer time reviewing code that has not met specific quality standards? Your source control tool can automate the code review process, establishing and enforcing quality gates in tandem with Git. Instead of being a passive component used only for managing source versioning and change tracking, it should become an active, intelligent component used to codify your best development practices.
The choice of a modern 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 organization to adopt Git as a corporate SCM standard is not merely a technical concern. It also has a major impact on the business performance of organizations. 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 Git deployment, these claims should be carefully evaluated against the fundamental categories of enterprise requirements:
- Ensuring security and compliance.
- Scaling Git.
- Support and enablement of best engineering practices
Understanding these key requirements lays the foundation for a well-articulated, comprehensive enterprise Git adoption strategy. Choosing an SCM technology that is ready for enterprise-scale deployment enables companies to achieve business agility without compromising on vital aspects of modern enterprise: manageability, scalability, compliance, and governance.
To learn more about Git Strategies, visit our Enterprise SCM Solutions Page.