Académique Documents
Professionnel Documents
Culture Documents
Executive Summary
With the rise in popularity of Distributed Version Control Systems (DVCS) in recent years, Git has gained momentum in pockets of enterprise environments. The concept of not having a traditional client/server model challenges some of the established enterprise Software Change and Configuration Mangement (SCCM) best practices and standards, while promising developer happiness. Very similar to the Agile movement that has been transforming the software world over the last few years, Git is rising to popularity because of developers passion for better software and efficiency. But is the enterprise ready to adopt an entirely new model of working, possibily sacrificing the process management and security aspects of traditional SCCM?
Even some of the early adopters of Git have had to plug the holes. Google soon suffered with some of its limitations with security and repository management. They invested resources to create additional tools to fully support their model, which was designed for Android development. Additionally, there is a
ramp-up time to learn Git, meaning command-line friendly developers might be able to learn it easily while other members of the team may take some time. Currently, GUI clients for Git are limited. With these gaps in mind, can you effectively adopt Git in your enterprise environment?
environment, often not knowing which repository is the official release candidate. In some cases, we might not end up with a good repository at all, and have to settle on taking a local developers repo. Simply put, Git doesnt give you an easy way to enforce your workflow because by design, the system is decentralized. It requires more communication and discipline to stick to the established rules that teams need. Additionally, with any workflow, there is often a separation of concerns based on role and user. Take into account the diagram of a Git repo workflow below:
With this model, developers are pushing from their local Git repos into development team repos and integrating and merging before pushing up to a INT stage, QA stage, and then to Production. The idea is to create a flow of the different code configurations while work is on its way to production. This starts on the developers desktop, but at different stages of the process, other people may have to produce official builds and releases along to the way. Those are the people who are responsible for that process. An example might be that a release engineer is responsible for the official build that is built from the stable repository. This means that there is a separation of concerns based on role for specific stages of the process, and while Git does lend itself to the ability to create these workflows, it often doesnt guarantee the ability to follow these processes without a high level of off-line communication.
With Git, developers can create quick, private branches, and if their changes dont work, they can get rid of those branches without anyone knowing. Its a great model to use to encourage experimentation and to isolate work for developers. In addition, Git has a built-in best practice of committing incomplete work, making sure that changes can be saved along the way. This is a paradigm shift from traditional systems, where committing is the same as publishing and sharing with the rest of your team. Trying to implement this on some traditional systems can be very difficult. One of the downsides of all this power is the concept of branching and merging locally, often creating ad-hoc branches and processes. These branches can be checked in, and pushed to other team members. This means that developers can basically create any branch they want, whenever they want, and because the systems are not centralized, developers dont know where changes should end up without extensive collaboration and communication. Very similar to Gits workflow model, its up to individuals interactions to manage this process. While this might be fine for twenty or so developers, it may not scale well when used in a distributed enterprise setting. In addition, understanding and managing change (SCCM if you will) is a concern. While Git gives developers all of the freedom they want on the desktop, it lacks traceability, meaning that understanding where change has happened and managing multiple release lines can quickly become complex and not easily understood.
Using Git with an Existing SCCM Solution (The best of both worlds?)
Gits core strength is that it makes developers lives easier and gives them all the tools they need to isolate and develop rapidly. On the flip side, enterprises crave control, process, and traceability. If we were to use Git as a developer-friendly tool to communicate with an SCCM system, would it be the best of both worlds? Because of Gits vast community, bridges exist to a large variety of other SCCM systems. This includes a Subversion bridge, AccuRevs Kando, ClearCase Bridge, which all allow developers to push Git changes into the enterprise SCCM repository. This allows developers to have the flexibility and speed of Git, but augment it with security, audit tracking, and development-process enforcement. This might be the best way to satisfy the needs of the enterprise with the developer community. Software configuration management experts know that they must work with whichever tools and processes are currently the standard while still striving to give developers an easy and straightforward way to work. Additionally, by removing the overhead of scripting or modifying Git to meet their needs, release engineers, development managers and QA teams can enjoy all of the traceability and release management functionality, and nothing has to change for them. When there is a separation of concerns to produce official builds with documentation and traceability, your team still has the ability to do so.
Conclusion
Gits functionality is heavily focused on developer productivity and making it easier for them to isolate and deliver change to their peers. On the surface, Gits DVCS architecture seems to break down the restrictions of the client/server based model, promising a better type of SCCM system. But as we examine closely, we can see that Git does lack some features, and that may make enterprises nervous to adopt Git. These reasons are: Lack of security and ACLs for teams who require security and regulation Process management and workflow for compliance and auditing Enforcement of SCCM best practices, because of Gits powerful nature, history is easy to delete Steep learning curve; it may not be suitable for all members of the organization Lack of GUI tools for people who live outside of the command line
Whether you are a developer advocating for Git or a manager who is just having Git show up on your radar, its important to understand these considerations. Having a tool that makes developers lives easier is very important, but you have to weigh the benefits. Is it possible to scale Git to the enterprise? Absolutely. Its amazing ability to provide local repositories with repository replication makes it architecturally more scalable than many SCCM systems. The trick will be the ability to use those features within an enterprise-ready SCCM context. With this said, it might be easy to think of Git as a distributed version control tool kit that can seemingly do everything we ask of it if we can surround it with the right tools and processes.
At AccuRev, our core expertise is process improvement. Weve got the expertise, coaches, trainers, consultants, and of course, the tools to help you successfully optimize a development process and best practices throughout the enterprise. In addition to product support, we offer a host of services designed to optimize your process and implement process improvements like multi-stage continuous integration.
Copyright 2012 AccuRev, Inc. AccuRev is a registered trademark of AccuRev, Inc. All other trademarks mentioned in this paper are the property of their respective owners.