Optimizing Your Software Process

GGiitt AAddooppttiioonn iinn tthhee EEnntteerrpprriissee:: FFaaccttoorrss ttoo CCoonnssiiddeerr

2

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?

Reasons for Developer Git Adoption Git is often adopted by development teams through a grassroots movement started by developers. The attraction to Git’s off-line DVCS repository makes it easy to work in isolation and integrate work with their peers. Additionally, DVCS can make some common SCCM operations much faster than a traditional client/server model.

But this isn’t the only reason why Git adopters are so passionate; Git has ‘street cred’ due to the fact that it was invented by the father of open source, Linus Torvalds. Git was a designed as a replacement for Bitkeeper to better meet Linus’s need to develop and maintain the Linux kernel. This model also lends itself well to the open source community model with which Linux is developed.

With these two distinct advantages, open source supporters and developers who crave DVCS features turn into champions within the organization and want to show others the benefits of working with Git.

When thrown into an enterprise environment, a small to medium group of developers may have great success when using Git. When scaling the solution, enterprise groups may have to consider the fact that Git lacks security, process management, traceability, and foolproof history. These groups of developers are often early adopters, attempting to achieve dramatic improvements by the adoption of this new technology. They are often focused on making the tools work and not thinking about the potential shortcomings of the software.

Additionally, the risks might not be fully realized or fully visible to the members of the team. Organizations may need to develop scripts and tools outside of Git itself to manage SCCM processes such as:

• Security with access controls and user groups

• Process management and workflow

• SCCM best practices

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

3

“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?

Security with Access Controls and User Groups Git does have authentication using secure SSH connections for remote access. But when it comes to file-level access and access control lists (ACLs), these types of security measures must be provided from a third-party vendor or by coding it themselves, sometimes even modifying Git itself.

Security in Git relies simply on the OS/file system or protocol (Git:, http:, or ssh: ) but only to secure read and write access to the repositories. If you want to add things like restriction by group or file-level ACLs, a homegrown script is the likely choice.

The advantage to the homegrown solution is that it can be made to work exactly to the requirements that you specify, so if you need security access for LDAP, you can build the integration.

The downside to this is cost and the expertise to doing it correctly. Implementation will require costly man-hours and scripting custom to your environment. In addition, you may end up with a customized version of Git for your company requiring maintenance and compatibly testing with the current Git releases. It’s an entirely new project that the team must maintain.

There are several third-party options such as Gitolite, Gitosis, and potentially Gerrit (which is more of a code review tool). These provide fine-grain access control, but also have their own shortcomings. For example, ACLs in Gitosis are all managed by editing a text file which can get complicated when managing more than a handful of users. The key takeaway is that Git does not do this out of the box. It will require some set-up, thought, and a fair amount of work depending on your configuration.

Process Management and Workflow One of the amazing features of Git’s DVCS architecture is the ability to push and pull changes from separate repositories. This gives teams a lot of flexibility when it comes to managing the process and creating custom code configurations for each step of the process. This means that a developer could create a release candidate repository with code just for that release, while letting dev teams keep their own version of the repo.

Git is excellent at creating new repos and dev branches and pushing and pulling these changes around to the different repositories. This works very well for a very large simple workflow, similar to the Linux kernel project. Yet, it lacks the visibility to make it work at scale for an enterprise. If the process is not clearly defined, teams can end up with many different repositories that are almost ad-hoc and disjointed.

Even with this ability to seeming create any combination of repositories and branches that we want (with blazing speed), Git requires that teams are more disciplined than they need to be when using a traditional client/server version control tool. Without discipline, teams will end up in an ad-hoc

4

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 developer’s repo.

Simply put, Git doesn’t 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 developer’s 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 doesn’t guarantee the ability to follow these processes without a high level of off-line communication.

SCCM Best Practices One of the best things about the Git DVCS model is the ability to use quick branching for developer experimentation. You can use branches in other tools, but they are heavyweight and often create more complexity than they are worth.

5

With Git, developers can create quick, private branches, and if their changes don’t work, they can get rid of those branches without anyone knowing. It’s 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 don’t know where changes should end up without extensive collaboration and communication. Very similar to Git’s workflow model, it’s 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?) Git’s 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 Git’s vast community, bridges exist to a large variety of other SCCM systems. This includes a Subversion bridge, AccuRev’s 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.

AccuRev, Inc. 10 Maguire Road

Lexington, MA 02421

Phone: +1 781-861-8700 sales@accurev.com www.accurev.com

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.

6

Conclusion Git’s functionality is heavily focused on developer productivity and making it easier for them to isolate and deliver change to their peers. On the surface, Git’s 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 Git’s 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, it’s 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. It’s 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. We’ve 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.