Use of 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 end-to-end development and testing.
It uses 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
Table of Contents:
TFS Tutorial
Introduction
TFS is tailored for Microsoft Visual Studio and Eclipse on all platforms, however, it can also be used as a back-end for 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 find out how to install agents.
Setup a C# Application
Assuming TASK work items are created by TFS and are assigned to developers 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, ensuring whether a Collection and Team Project exists or not.
The Collection was 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 project 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 projects can be created using various inbuilt process templates like Scrum, Agile, CMMI, etc.
- More on creating collections that can be found @ Manage team project collections in Team Foundation Server
- Here, I will be using the Default Collection which will be created once TFS is installed
- To create a 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 be able to get on to the Team Dashboard
(Note: Click on any image for an enlarged view)
We now 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 be open. We need to add a 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 Team Explorer, click on the source control explorer and you will 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 in any particular environment.
Creating Build Definition with Code Analysis
A build definition consists of a series of Tasks which are 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 the TFS web interface and go to the Builds TAB. Click on + to create a build definition. Start with the EMPTY definition and then click Next.
Select the Team Project and click on Create
Click on Edit, which can be 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 the SonarQube server to configure the analysis.
Add End Analysis steps later on.
The steps added will look like the following with the MS Build step in between.
Start defining the details of the SonarQube server. Define the 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 that 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 steps to Publish Artifacts to the server. The artifacts will be stored in a drop folder on 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 find out 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 it to the SonarQube installation\extensions\plugins 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 the Artifacts tab to look at the drop folder created at the server level.
Note: In the next section, the release process shows how any 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 the compilation step or manually copy the project artifact directory to the C:\inetpub\wwwroot directory.
This has to be done only once.
Create 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 will be automated to the entire environment one after the other.
Link the Build definition to the Release definition so that 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 Trigger for deployment after the build is successful. In the Release definition, go to the Trigger tab and enable .Continuous Deployment and select the build definition.
Later Save the Release Definition.
Back in the Environments tab of the release definition, add the tasks to deploy the artifacts to the IIS server.
Add a task to copy files from the ‘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 inetpub\wwwroot directory – C:\inetpub\wwwroot\WebApplication1
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 in QA environment.
Run inetmgr which is the IIS manager, where you can manage all the websites/applications installed to IIS. Browse the web application deployed.
Once you initiate the Build, the deployment will also get completed in all the environments defined, as the Release is linked to the build definition.
Conclusion
In this TFS tutorial, we have now seen how the Microsoft ALM platform can be used to automate 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.
What did you think about this article? Please post your feedback in the comments section below. We would love to hear from you.
If you are achieving the CI/CD process using TFS Builds and release, why do we need AZURE Develops which should have paid subscriptions ?
Once i check-in the code into TFS, automatically it can build the dll and paste it in website ?
could you please help me on this
Under the section: Setup A C# Application
I get a 404 page for the link: “More on creating collections can be found @ Manage team project collections in Team Foundation Server”
In Creating Build Definition With Code Analysis
Your reference: “2) Install the agent on the Build and Deployment machine. You can refer to my previous tutorial…”
A link would be good there, I cannot immediately find that tutorial.
How to Use TFS build automation for other than .NET applications Ie Java, Python etc..and also how do we integrate TFS deploying build in Azure instance?
I am beginner to .Net Framework. I am obliged for this informative post, I have got many new points and has cleared my doubts. It also helped me understand this topic in more detailed way.
how to useful for Testing and where will be QA the part in TFS
You got answer?
Hello Author,
this blog was very useful, it would be great help if you post how to Build and release to a database and if possible how to do when we have multiple databases in an instance.