Introduction

Code repositories enable developers to write code more confidently. More developers are using source control than ever before. The most obvious benefits of a code repository can be seen when multiple developers are collaborating on code. Many hands in the pot means there is a greater need to manage and understand revisions. If you ever have to make an argument to support source control, then the questions to ask would be the following:

• Have you ever made a change to code, realized it was a mistake and wanted to revert back?
• Have you ever lost code or had a backup that was too old?
• Have you ever had to maintain multiple versions of a product?
• Have you ever wanted to see the difference between two (or more) versions of your code?
• Have you ever wanted to prove that a particular change broke or fixed a piece of code?
• Have you ever wanted to review the history of some code?
• Have you ever wanted to submit a change to someone else's code?
• Have you ever wanted to share your code or let other people work on your code?
• Have you ever wanted to see how much work is being done, and where, when, and by whom?
• Have you ever wanted to experiment with a new feature without interfering with working code?

Managing code is an essential part of Application Lifecycle Management, which spans indiscriminately across programming languages and frameworks. Source control systems can broadly be distinguished as centralized or distributed:

Centralized Version Control Systems (CVCS) maintain a single "central" copy of your source code on a server repository. When working with a centralized version control system, developers download the code from the repository to a local workspace. Once changes to the code have been made locally, they are committed to the centralized copy. Additional functions against the repository (branching, merging, shelving, and so on) also take place on the server and require a connection to the server.

TFVC is a Centralized Version Control System. When working with TFVC using Visual Studio or Eclipse, the IDE is in frequent communication with the server. Most common operations cannot be performed in the absence of an active connection to the server.

Distributed Version Control Systems (DVCS) does not necessarily rely on a central server to store all the versions of a project's files. Instead, developers "clone" a copy of a repository and have the full history of the project on their own hard drive. This copy (clone) contains all of the data in the repository – all of the branches and the commit history.

Git is a Distributed Version Control System. Most operations (except pushing and pulling) can be performed without an active connection to the server.

TFS is the only platform to support both centralized (TFVC) and distributed (Git) source control systems. The following table should help you decide when centralized is a better option than distributed. More details on the differences between the two can be found at https://msdn.microsoft.com/en-us/Library/vs/alm/code/overview.

Until TFS 2015, the selection for source control type needed to be made at the time of Team Project creation. In Update 1, a new capability was introduced that allows Teams to create Git repositories within TFVC Team Projects. This is great for Teams that have large investments in TFVC projects but would like to try out Git. This capability and its advantages are discussed at length in the Creating a Git repository in an existing TFVC Team Project recipe. The Git for TFVC users is a very useful guide (http://bit.ly/1RgboRk) for anyone coming from a TFVC background interested in learning Git.

Today, the marketplace and business demands are changing more than ever before. Development Teams are constantly under pressure to deliver better quality software faster. This is not sustainable unless the underlying codebase is of good quality and backed by unit tests. A good source control repository can significantly contribute to the quality of the software, but it requires much more than just a good source control repository to drive quality.

Talking of quality, no code reviews, poor DevOps practices, lack of unit tests, too many tactical implementations, and not addressing underlying issues are major contributors to technical debt. Technical debt doesn't hit you overnight, it's a slow and gradual process. Unlike financial debt, technical debt is very hard to recognize. Technical debt will slow your ability to deliver value. Are you seeing any of these signs?

The goal of this chapter is to introduce you to various source control operations in Web Portal and Team Explorer, learn about features that help build quality into the code, and last but not least, understand the code metrics available in the TFS Warehouse. In this chapter, we'll be using the Fabrikam Fiber codebase available on CodePlex (https://fabrikam.codeplex.com). Follow the following instructions to set up the code in the FabrikamTFVC and FabrikamGit Team Project.

Setting up the Fabrikam solution in FabrikamTFVC Team Project

1. Open Visual Studio, and in Team Explorer connect to FabrikamTFVC project. Click on the hyperlink to configure your workspace. Accept the default name and location, and click on Map & Get. A success notification is shown when the operation is completed:
   
2. Open the workspace location, in this case, C:\Users\Tarun\Source\Workspaces\FabrikamTFVC. Create a new folder Main; in Main, create a folder Source and copy the content of Fabrikam codebase downloaded from CodePlex:
   
3. Open Source Control Explorer in Visual Studio and from the menu bar, select Add items to folder icon. In the Add to Source Control window, click on the Main folder and then click on Next. Following this, click on Excluded items, select all the items, and then click on the include item(s) icon. There should be no excluded items now. Click on Finish, and then click on the FabrikamTFVC project and choose Check in pending changes from the context menu:
   
4. In Source Control Explorer, right-click on the Main folder and select Convert to Branch... from under the branching and merging submenu in the context menu:
   
5. Open FabrikamFiber.CallCenter.sln from $/FabrikamTFVC/Main/Source/FabrikamFiber.CallCenter. Right-click on the Solution in Solution Explorer and select Add Solution to Source Control... from the context menu:
   
6. Accept warnings and check in the changes from the pending page in Team Explorer. The Fabrikam solution is now successfully set up in the main branch in the FabrikamTFVC Team Project.

Setting up the Fabrikam solution in FabrikamGit Team Project

1. Open Visual Studio and in Team Explorer, connect to the FabrikamTFVC project. Click on the hyperlink to clone this repository. Accept the default name and location and clone. A success notification is shown when the operation is complete:
   
2. Open the local working directory, in this case, C:\Users\Tarun\Source\Repos\FabrikamGit. Create a new folder src and copy the content of the Fabrikam codebase downloaded from CodePlex:
   
3. In Team Explorer, navigate to the changes page. From the untracked files section, click on the Add All hyperlink to include all files recently copied into the working folder. Click on the Commit button to commit these changes to the repo:
   
4. A prompt to sync the changes is raised when the commit operation has been successfully completed. Click on Sync and then on Push from the Outgoing Commits (1) section to push the changes to the remote server:
   
5. Navigate to the branches page in Team Explorer. The master branch shows up as well as the remotes/origin branch:
   

The Fabrikam solution is now successfully set up in the Master branch in the FabrikamGit Team Project.