TFS Tutorial: TFS for Automating Build, Test, and Deployment for .NET Projects

Using Microsoft TFS 2015 Update-3 for .NET (Build, Test and Deploy): TFS Tutorial

TFS is more widely used for .NET development using Visual Studio .NET IDE. With TFS 2015 Update 3, one can connect to any Team Foundation Server Git repo, using an SSH key.

Team Foundation Server (TFS) is an ALM product from Microsoft which provides the capabilities for an end-to-end development and testing using Work Item Management, Project Planning (Waterfall or Scrum), Version Control, Build/Release (Deploy) and Testing capabilities.

NOTE: This TFS tutorial has many images so allow it to load properly. 

Also read => TFS for JAVA Projects with Eclipse in DevOps

Introduction

TFS is tailored for Microsoft Visual Studio and Eclipse on all platforms, however, it can also be used as a back-end to several IDEs (Integrated Development Environments).

We will now take a look at how Team Foundation Server (TFS) will be used to Build, Test and Deploy .NET Web Applications which is traditionally the strength of the tool.

Prerequisite:

• Microsoft TFS 2015 Update 3
• Microsoft Visual Studio .NET 2015 (30-day trial version)
• SonarQube 6.4 or above
• IIS Web Server Enabled. Since I am using a Windows 7 box you can check this tutorial on how to enable IIS 7. How to Install Internet Information Services (IIS 7) on Windows 7 Ultimate
• There are several YouTube videos on how to enable IIS on Windows 2008 / 2012 / 2016.

Typically to perform the steps mentioned in the tutorial you will need a Build Server, where Builds will be performed, and Deployment machines or environments where, applications will be deployed to IIS, with agents installed and running. Please refer to my earlier tutorial to know how to install agents.

Setup a C# Application

Assuming TASK work items are created in TFS and is assigned to developer’s to work on the same. I have always noticed that Traceability is very important from the point of view of tracking any work across the software lifecycle.

Before adding a .NET application to TFS source control repository, ensure whether a Collection and Team Project exists or not.

A Collection is created by the TFS Administrator. It consists of a group of Team Projects in any service organization, where projects for multiple customers are being executed. You can create individual collections for each customer projects in TFS.

Once a collection is created you can create multiple team projects within it. A single team project consists of all work items, source code, test artifacts, metrics for reports etc., Team project can be created using various inbuilt process templates like Scrum, Agile, CMMI etc.

• More on creating collections can be found @ Manage team project collections in Team Foundation Server
• Here, I will be using the Default Collection which is created once TFS is installed
• To create team project within a collection, follow the steps as shown below.

Launch TFS Web interface using the URL http://<ServerName>:port/tfs and you can see the project created.

 

Click on the project and you will get on to the Team Dashboard

(Note: Click on any image for enlarged view)

Now we have a collection and a team project created. Let’s launch Visual Studio.NET and create a new C# Web application and share the project to TFS source control repository. This is the first step towards establishing Continuous Integration (CI) practice.

1) Launch Visual Studio.NET and set TFS as the default source control repository. Go to Tools => Options => Source Control. Then click OK.

2) Go to View => Team Explorer and connect to TFS server using the icon

3) Create a C# ASP.NET Web project

4) Since we are creating a web application, Select the Web Forms template

Click OK to create the project.

5) The project created can be viewed in Solution Explorer. .NET uses the concept of .sln file or solution to contain all the projects. Once you open the solution all the associated projects will also open. We need to add the solution to the TFS source control repository

 

6) Modify the file Default.aspx as shown, Save it and then add the whole solution to the TFS source control repository

 

Select the Design view and you will be able to see the entire page

 

7) Add the solution to TFS source control. Right click on the solution and select ‘Add solution to Source Control’

 

8) Select the Team Project created earlier and then click OK

 

9) The solution is not yet checked-in to the TFS. In the Team Explorer click on the source control explorer and you can see the solution added to be checked in.

 

10) Check-in changes. Go to Team Explorer => Pending Changes

Enter a comment and drag-drop a TASK work item to ensure traceability. Click on the Check-in button.

11) To test the website running locally, Click on the Firefox icon in Visual Studio.NET. Remember it is not yet deployed to IIS on any particular environment.

Creating Build Definition with Code Analysis

A build definition consists of a series of Tasks which is executed during an automated build process. Examples of the tasks can consist of running a Visual Studio Build, MS Build, executing PowerShell or Shell scripts etc.

1) To create a Build Definition, login to TFS web interface and go to the Builds TAB. Click on + to create a build definition. Start with EMPTY definition and then click Next.

Select the Team Project and click on Create

 

Click on Edit, which is found next to the Empty definition

 

Save the build definition as something like ‘Main Build’

 

Since Sonarqube will be used for Code analysis, hence add the 2 Sonar steps ‘SonarQube Scanner for MSBuild – Begin Analysis’ and the ‘SonarQube Scanner for MSBuild – End Analysis’ tasks.

Add the Begin Analysis step before any MS Build or Visual Studio Build. This step fetches details from Sonarqube server to configure the analysis.

Add End Analysis step later on.

 

The steps added will look like the following with MS Build step in between.

Start to define the details of Sonarqube server. Define Endpoint where the Sonarqube server and authentication details are added. Click on ‘Manage’ to add the Sonarqube server details.

Click on ‘New Service Endpoint => Generic’

Now go back to the main Build Definition screen and select the endpoint which was just created.

Completed configuration for Begin analysis, looks as shown below

 

Select the solution. In the Advanced => Additional Settings enter the following and save the Build Definition

/d:sonar.scm.enabled=true /d:sonar.scm.provider=tfvc /d:sonar.tfvc.username=niranjan /d:sonar.tfvc.password.secured=<password>

 

SonarQube – End Analysis. Finish the analysis and then upload the results to the SonarQube project.

 

Add a step to Publish Artifacts to the server. The artifacts will be stored in a drop folder in the server and will be used during deployment.

 

2) Install the agent on the Build and Deployment machine. You can refer to my previous tutorial to know how to install the agent. Now assuming that the agent is installed, ensure whether the agent is running or not.

 

3) Ensure the SonarQube SCM TFVC plugin is downloaded from here. and copied to the SonarQube installationextensionsplugins directory. This plugin ensures that the source code is taken from the TFS source control repository and is made available to SonarQube for code analysis.

 

4) After the plugin is downloaded and copied, Launch the sonar server

5) Initiate a Build to check if the steps work fine. Open the Build Definition and click on ‘Queue Build’

 

Build Successful. All the steps ran fine.

 

Click on the Build number, in this case, it is Build 217 and go to Artifacts tab to look at the drop folder created at the server level.

 

Note: In the next section the release process shows how any of changes can be reflected throughout the deployment process. For this ensure that the project artifacts are copied through the COPY step in the build definition after compilation step or manually copy the project artifact directory to the C:inetpubwwwroot directory. This has to be done only once.

 

Creating Release for Deployment

In the previous section, we saw about Build, followed by code analysis using SonarQube. We will now create a Release to deploy the artifacts from the ‘drop’ folder to IIS.

With the creation of Release, the entire Continuous Integration and Continuous Delivery is automated without any manual intervention.

Go to Release hub and Create a Release Definition.

 

Start with Empty definition and click OK.

 

Save the Release definition and rename the Default Environment to QA. Based on the projects, additional environments like Staging Pre-Prod etc. can also be added and deployment would be automated to the entire environments one after the other.

 

Link the Build definition to Release definition so as the deployment is automated. Click on ‘Link to a build definition’. Select the build definition created earlier.

 

Click on Link

Enable the Deployment Condition to initiate the deployment immediately after Release creation

Also, enable the Trigger for deployment after the build is successful. In the Release definition, go to the Trigger tab and enable ‘Continuous Deployment’, select the build definition.

Later Save the Release Definition.

 

Back in Environments tab of the release definition add the tasks to deploy the artifacts to the IIS server.

Add a task to copy files from ‘drop’ folder created during the build process to IIS wwwrootdirectory.

Source folder – Browse and select the Webapplication1 project in the drop folder

 

Target folder should be the inetpubwwwroot directory – C:inetpubwwwrootWebApplication1

Executing Release for Deployment

In the release hub, create a release to start the deployment

 

Select the last stable build and Click on Create to Start the Deployment.

 

Deployment is successful to QA environment

 

Run inetmgr which is the IIS manager, where you can manage all the web sites/applications installed to IIS. Browse to the web application deployed.

 

 

To conclude once you initiate the Build, the deployment will also get completed to all the environments defined, as the Release is linked to the build definition.

Conclusion

In this TFS tutorial, we have now seen how Microsoft ALM platform can be used for automating Build, Test, and Deployment for .NET applications. TFS plays a major role here.

Hence in today’s world, AUTOMATION is the key for successful and faster delivery to stay ahead.