For a digital entity to develop consistently and strategically, it is imperative to ingrain and scale Version Control best practices and DevOps patterns. Having a clear understanding of how to both collaboratively use version control and gain necessary software engineering skills and discipline will allow your organization to benefit in several ways, through practices such as:

• Identifying patterns and relationships to release high-quality software
• Defining and implementing useful policies
• Assuring secure and reliable access to your organization’s code assets

This information is relevant to any version control tool. Further, due to its majority place in the industry, Git is referenced and elaborated on in this article which proposes to take a new look on a new day at something we take for granted.

Code Management

It’s a new day and you’ve begun to take stock in your version control system (VCS) practices.To bring a world-class practice to your organization, it is important to go through the roadmap and onboarding. It’s important to note that a code management engine is on the same playing field as many other mission-critical software technologies. Further, for CI/CD pipelines this is an early gate, or a start of everything measured. Lastly, considering DevOps and software-defined infrastructure, let’s address the subject of developers and code management by asking the questions:

• By what means do developers and teams feel connected and committed to the process?
• Do they act responsibly and use version control in a consistent manner?

If we identify the right patterns for code management, it only manifests itself into high quality software as a connected practice across the release process, methodology and pumping deliveries through your pipeline. This is the context. The diagram below is not ubiquitous; one size does not fit all. It is illustrative of the idea that version control should be viewed in a broader context. The spectrum consists of many moving parts, especially through a CI/CD pipeline, such as testing, change, planning and managing. Rather than get absorbed by specific tools, the essential task is to first settle on process and people.

3 Best Practices for Enterprise-wide Adoption

In the early days of my career, I became a fan of source code control, and soon after tasked to influence people in my company to adopt Version Control and associated best practices. The resistance was abundant. It felt like I was a lone soldier facing guerrilla warfare tactics.

To encourage adoption, a system needs to be implemented that protects your assets. For starters, it follows a resilient pattern of DevOps and Infrastructure as Code, essentially intertwined with version control. An organization’s first quality gate in a CI/CD pipeline is effective version control practices and strategies.

Here are some tried-and-true practices to successfully scale with Git enterprise-wide:

Train your people

Find the principles important and inherent in the VCS that you have selected. Common examples are: branching and merging strategies; repository structure; repository ownership; and access across the organization.

Purists will say that Trunk-Based Development is the definitive archetype, whereas branches are the anti-pattern. However, Gitflow works and mirrors what people like to do. Also, there is a path forward from GitFlow, as it uses branches in your software development in an organized fashion, thus having short-lived branches that merge back to master or Trunk is effective. However, I digress; this is a huge leap. Let’s get back to basics and get your people onboarded.

How do you train your teams?

1. Integrate training into your enterprise learning system (Saba Cloud, for example).
2. Identify web-based resources such as the Git You can download resources from there, and there’s a wealth of information.
3. Do a roadshow with a couple of champions! Organize boot camps in more concentrated locations. These are successful for several reasons: They have catchy names and it can be implemented as a program throughout the year, therefore repeating topics, recording sessions and getting input from the community. Go to the VCS reference guide for help in finding compelling topics by picking out the most useful commands to begin. For Git, I would then use a session to compare rebase and merge. In another useful topic, present the available clients for Windows and Linux.
4. Make training a community effort. GitHub refers to its website as “social coding.” In the spirit of all things social, collaboration is a huge pull for developers.
5. Acknowledge and spread the idea that this is an investment in your people. In the DevOps arena, this has associated numbers for employee retention and an upskilled organization.

Standardize on a tool and support it

You already have a VCS. If you have legacy VCS still in use and you are focused on Git across the enterprise, then you should normalize to a single tool. VCS is really a platform; the code is fairly easy to move. That said, it requires time to integrate a new VCS into your CI/CD pipeline since you’ll already have trained your people.

The main areas to consider when implementing version control in your organization include:

• What VCS do you already have in your midst?
• What are your licensing costs? Open source solutions work, but for an enterprise protecting your software – the life blood of your digital existence – free only gets you so far.
• What is your VCS server environment and life cycle structure like?
• Are your hundreds of AppDev and infrastructure developers all working off one VCS system running underneath your code evangelist’s desk?
• Are you using a SaaS implementation without Two Factor Authentication, such as GitHub.com?
• Do you have Dev, Test, and Prod lifecycle for your VCS? In other words, do you treat your code repository management like any other system, be it ERP, CRM or SCM (Supply Chain Management and not Software Configuration Management)?

In the simple illustration here, having multiple sites and DR will fit into your diagram. This clean approach provides your System Administrators with the opportunity to upgrade the VCS, test and integrate as you would any mission-critical application. Being that Digital Transformation needs code, this visibility into managing a “development” function is often missed and not well understood.

In short:

1) The purpose of acknowledging this is that all too often, code repositories are not tracked. Disparate version control systems are not the same as Distributed Version Control Systems (DVCS), and 2) Lost code is digital defamation.

Collaborate and scale

This is important to your release methodology. To implement the right practice, your team needs to understand where the code is going, and that code cannot go anywhere if the quality and quantity approach is not correct.

You should be implementing methodologies as part of your VCS use and release methodology.

For example:

• Know your Git, use its features with confidence to revert and commit
• Feature branches to Release branches
• Test before merge {feature branch} and test after merge {develop branch}
• Protect milestone branches in Git
• Use for Code promotion {release branch for Non-Prod}
• Use tags for added traceability for your end to end release process

Key Terms to Foster Effective Conversations

Moving on, it is important to review some basic terminology owing to this established practice:

1. Version Control System (VCS)
2. Branch
3. Peer Review
4. Baseline

Code Repositories Are Not a Fileshare

Although sharing can be nice and helpful, in the source file realm, filesharing tends to mean collaborating.  Unfortunately, the code repositories often become like one big fileshare. Fileshare syndrome can cause a pack rat mentality around your VCS. It’s not workable, strategic, roadmap-worthy or sensible, and it slows down your entire CI/CD pipeline performance, as well.

In my experience, when it comes to managing files, no matter the source or documentation, a target system without crafting and adopting best practices turns into a file share repository more than anything else. The simplest way to avoid this is to not upload binaries, only your source code. Primarily, these should be text files that the versioning engine can break down into deltas to allow easy file compares. Binaries like executables belong in the artifact repository, where they are versioned in their own right, but they are also segregated across the CI/CD pipeline.

Now that you have the right files stored and versioned, you must ensure that your code structure matches recommendations for the software language or technology in use. Smaller repositories are an effective way to manage components or microservices, but this is a larger topic that goes beyond the scope of this blog.

Summary

When taking a fresh look at your Version Control practices, there are a few important components to understand. Developers may know the basics, but they must see the bigger picture in the CI/CD pipeline. Training needs to be tailored to your organization, so people can build the social context when writing code and encouraged to reuse and refactor it. Lastly, ascertain your code review processes are evolving and keeping pace with your parallel efforts to avoid branch sprawl. A well-trained developer, either in AppDev or Infrastructure, is the foundation to a high-performing organization and high-quality software delivery.