Source Control

In the previous step, we briefly discussed environment deployment and configuration. In this step, we delve into environmental configuration by exploring source control.

To fully realise Infrastructure as Code (IaC), environmental configurations must be source-controlled.

Source control:

• Is usually supported by a tool.
• Provides ways to visualise differences between versions.
• Provides a way to see version and check-in history at any given point in time, including who made changes and what was changed.
• Allows parallel development through merges and branches.
• Is integral to software development, but occasionally new to operations teams.

In DevOps, both the development team and the operations team should be using the same source control. For example, when a new version of an application is deployed, the environmental configuration for that version should roll with all the developmental changes.

If changes must be rolled back, then when we return to an earlier version in the code, we get the earlier deployment scripts and the earlier environmental configurations so that everything works as planned.

In DevOps, everything should be source-controlled so that you can work together between dev and ops, roll out a particular version through the deployment pipeline, and get what you’re expecting each time without error.

Items that should be source-controlled include:

• Source code
• Environmental definition
• Infrastructure configuration
• Deployment scripts
• Documentation
• Tests (unit tests, integration tests, etc.).

Version Control Software: GiT and TFVC

There are many options available for source control software. In this section, we focus on Git, a very popular open-source distributed model versioning tool, and Team Foundation Version Control (TFVC), a centralised version control system that’s available in Visual Studio Team Services (VSTS). In Git, changes can be pushed or pulled across repositories on different machines. VSTS supports both Git and TFVC.

Git (distributed)

Git is a distributed version control system. Each developer has a copy of the source repository on their development machine. Developers can commit each set of changes on their development machine and perform version control operations such as history and compare without a network connection. Branches are lightweight.

When you need to switch contexts, you can create a private local branch. You can quickly switch from one branch to another to pivot among different variations of your codebase. Later, you can merge, publish, or dispose of the branch.

TFVC (centralised)

TFVC is a centralised version control system. Typically, team members have only one version of each file on their development machines. Historical data is maintained only on the server. Branches are path-based and created on the server.

TFVC has two workflow models:

• Server workspaces: Before making changes, team members publicly check out files. Most operations require developers to be connected to the server. This system facilitates locking workflows. Other systems that work this way include Perforce and CVS.

• Local workspaces: Each team member takes a copy of the latest version of the codebase with them and works offline as needed. Developers check-in their changes and resolve conflicts as necessary. Offline, developers can even Diff the changes they made against the latest version and undo those changes. Another system that works this way is Subversion.

If you have existing TFVC repos, you can migrate them to Git repos by using the git-tfs tool. The tool allows you to migrate a TFVC repo to a Git repo in just a few commands.

Additional information

• Getting started with Git: About Version Control.

• TFVC: Use Team Foundation Version Control.

• A comparison of TFVC and Git as source control solutions, including server capabilities, client capabilities, and integration and migration capabilities: Git and TFVC Capabilities.