Release Management with TFS

Release Management is a service in VSTS Azure pipelines and TFS on-premise and an essential element of DevOps that helps you continuously deliver software. We can fully automate the testing and delivery of your software in multiple environments all the way to production, or set up semi-automated processes with approvals and on-demand deployments.

CI Build

Release definition defines the end-to-end release process for an application to be deployed across various environments.

You define the release process using environments, and restrict deployments into or out of an environment using approvals. You define the automation in each environment using phases and tasks. You use variables to generalize your automation and triggers to control when the deployments should be kicked off automatically.

You can create a deployment model on the basis of how you manually deliver the builds using build definition for different environments.

The below Release Definition shows different steps using PowerShell scripts that are modeled basis the manual process created for deployment.

Release definition

 

Creating a Release definition

Configure your environment:

  • Give the environment a meaningful name by clicking into the Default Environment name provided and enter one of your own e.g. DEV, QA, PRODUCTION.
  • Click on the ellipsis next to the environment name and select Deployment conditions…

rd1

 

Deployment Conditions

rd2

This is where we set up how we want our deployment to be triggered. It is here that we define what triggers the deployment of our release.

  • No automated deployment– deployment of the build artifacts will need to be undertaken manually with no automation
  • After release creation– this will deploy the build artifacts to the specified environment every time a new release is created i.e. Continuous Delivery.
  • After successful deployment on another environment– this will deploy the build artefacts to an environment after they have been deployed to another environment e.g. after every successful deployment to the STAGING environment deploy the build artefacts immediately to the QA environment

Use the first option if you are deploying to a production environment i.e. make the deployments to your production environment a manual exercise. Use the second option if you are deploying to a development testing environment as part of a Continuous Delivery pipeline. Use the last option if you want to push your deployments between different testing environments.

Approvals

You may setup Approvals before the deployment to a particular environment using the Approvals Tab.

rd3

 

Configure a Queue and set demands

The demands may be System defined like “DotNetFramework” or you can set yourself like selecting Agent name.

rd4

 

General Tab

rd5

 

After configuring your environment, the next step would be to add task(s) which will be invoked when we want to deploy our build artifacts to the specified environment. The deployment task is the action that we want to happen when we invoke a deployment e.g. running a PowerShell script to start/stop App Pool, running database scripts, deploy the build on to a Virtual Machine or Azure instance.

Create Release

Create Release and select the build for which you would like to create a release in Dev environment and click on Create as shown below:

rd6

The successful build selected above will trigger the Automated Deployments based on the selections made for each environment.

Create build definition with TFS 2015 or newer

What is build definition?

A build definition is a representation of the automation process that you want to run to build and test your application. The automation process is defined as a collection of tasks. VSTS and TFS have a number of tasks to build and test your application. A build definition describes the details of what your build is supposed to do, and when it’s supposed to do it.

Build and Release are two of the DevOps services in VSTS and TFS that help you manage continuous integration and delivery of your applications.

Visual Studio Team Services (VSTS) and Team Foundation Server (TFS) provide a highly customizable continuous integration (CI) process to automatically build your Web, Mobile or Desktop application whenever your team pushes or checks in code. You can also Schedule builds on a specific date or time, recurring builds or manually queue a build.

You can add build tasks for .Net, Java, Node, Android, C++, xcode applications. Similarly, there are tasks to run tests using a number of testing frameworks and services. You can also run command line, PowerShell or shell scripts in your automation pipeline.

A basic build definition consists of 3 steps or build tasks which can be used with the Visual Studio template (this template requires Visual Studio be installed on the build agent):

  1. Visual Studio Build: This step builds the solution in the $(build.sourcesdirectory). This is the Source directory with the letter “s” under the Agent’s work folder. TFS gets all the files under this directory and builds the application under the bin folder. Provide the path to the solution that requires to be built. In case you need to build a web application, fill the msbuild arguments with: /p:DeployOnBuild=true /p:PublishProfile=<name of Publish profile>. Make sure the Publish profile is checked-in.BuildStep1
  2. Copy Files: This step copies the files from the source directory described above to the Artifacts Staging directory $(build.artifactstagindirectory) with the letter “a” under the Agent’s work folder. The Files Published for the Web Application can be found under bin\$(BuildConfiguration)\Publish folder.BuildStep3
  3. Publish Build Artifacts: This step Publishes the artifacts in step 2 to the Shared folder for which Network share path requires to be provided. Appropriate permissions are required on the folder to the same user that is running the Build Agent Service on the Agent machine. You can Publish the files copied in step 2 from the Publish folder above to the Network share path for continuous delivery pipeline. BuildStep4
Repository Tab

This tab lets you specify the Mappings under the Source “s” folder on the Agent machine as to how it should manage the downloaded source files locally. You can map each Server paths with a local path e.g. one Server path may be mapped to Application files and other Server path may contain PowerShell scripts which may need to be run in a different build task.

General Tab

This tab specifies some of the required demands that are defined as capabilities on the Agent machine like:

  • msbuild
  • visualstudio
  • vstest etc.

You can specify additional demands like choosing a specific agent by adding a demand as “Agent.Name”.

The Build Number format specifies the name of the folder under which queued build will be placed.

Variables Tab

This tab holds some predefined system variables and link to the entire list of it. You can also add your own variables which can be used in the build definition.

Triggers Tab

Specify whether to schedule the build, build with each check-in or with gated check-ins.

Retention Tab

Lets you specify the duration until which you’d like to keep the queued build.

History Tab

Shows the log of any changes made to the Build definition by which users and when.

Configure TFS 2015 Agent

What is TFS Agent?

An Agent is an installable software that runs one build or deployment job at a time.  At least one Agent is required to build or deploy your code. More agents are required as people and code grows.

Agent types:

There are two types of Agent:

  • Microsoft-hosted agents: These are run in Azure pipelines on Microsoft virtual machines which are discarded after one use.
  • Self-hosted agents: These can run in Azure pipelines or TFS on-premise.

Agents can be installed on Windows, Linux or MacOS machines. Linux Docker containers can also be used.

Agent pools:

These are used to organise agents based on Project collections and Projects, so that agents don’t have to be managed individually.

Pre-requisites:
  • An OS that supports VS 2013 or higher
  • VS 2013 or 2015 (For information on issues faced with VS latest versions. Check this article)
  • PowerShell 3 or higher
Capabilities:

This tells us what the agent can do. Capabilities are name-value pairs that are either automatically discovered by the agent software, in which case they are called system capabilities, or those that you define, in which case they are called user capabilities. While queueing a build these can be set as demands in the General tab to identify suitable agents.

These capabilities are recognised by the registry information which can be found under HKLM on Windows machines.

Some of the generally required capabilities are:

  • msbuild
  • visualstudio
  • vstest
  • Microsoft SDKs
  • PowerShell

Additional software can be installed on an Agent as required by the code to be built e.g. a software that packages your code after build in an MSI and can be invoked by a build task in your build definition through batch file or PowerShell command.

Additional Tip:

Restart the Agent service after installing additional software for the capability to show up.

Download and configure the Agent:

  1. Login as Agent Pool Administrator.
  2. Navigate to the Agent Pool tab: http://{your_server}:8080/tfs/_admin/_AgentPool
  3. Click on Download Agent. Unzip the package under C:\Agent.
  4. Run “ConfigureAgent.cmd” as administrator and respond to the prompts.
  5. Stick to the defaults initially to install the agent in the Default pool if you’re not really familiar with the environment.
  6. Install the Agent as a service. Make sure the Agent is running under Services.msc with the provided domain credentials. The credentials should have required permissions e.g. on the Drop folder where the code will be Published using the Build definition.
  7. The C:\Agent\Agent\VsoAgent.exe is found under Services snap-in as VSO Agent.

If you need to change the credentials later the following command can be used:

C:\Agent\Agent\VsoAgent.exe /ChangeWindowsServiceAccount

The TFS on-premise agent cannot be upgraded unless the TFS version is upgraded. The Agent version which is used which is shipped along with TFS.

The list of configured Agents can be found under:

http://your_server:8080/tfs/_admin/_AgentPool

 

Unconfigure Agent:

Start cmd as Administrator.

Go to the Agent folder C:\Agent\Agent and Run the command –

.\agent\vsoagent.exe /unconfigure

 

Comments are welcome for improvements!

Setup Unit Testing with TFS 2015

Create unit test project in solution

To get started with Unit Testing your Project along with the DevOps Process, we need to add Unit Test Project in your solution. E.g. if we have a web application, add the Unit Test Project the following way:

  1.  Right-click solution
  2. Add New Project
  3. Select Unit Test Project as shown below

Any Unit Testing framework like MSTest or NUnit can be used to create unit test cases.

UnitTestProjectTFS

Add Unit Test Cases

Following the convention of adding Unit test cases, add a class with same name of the class whose functionality requires to be unit tested with “Test” as suffix in the name.

Below is an example of dummy test-cases. The class name can be changed accordingly.

E.g. for a class named “Upload.cs”, add a unit test class named “UploadTest.cs”.

dummyTestCases

The test cases can be tested by:

  1. Right-click inside a method to run that single test case.
  2. Right-click inside the class outside all methods to run all test cases.
  3. View the results in the test explorer.

TestExplorer

We have AAA pattern to write Unit Test cases:

  1. Arrange all the necessary preconditions and inputs.
  2. Act on the object or method under test.
  3. Assert that the expected results have occurred.

 

Build definition with test step

Create a build definition with the following tasks for your environment.

e.g. To test your Dev environment build add the following build tasks. Please note the configuration may change as per requirements:

  1. Visual Studio Build to build the solutionBuildStep1
  2. Visual Studio Test to run the test casesBuildStep2
  3. Copy Files from Source directory to artifacts staging directoryBuildStep3
  4. Publish Build artifacts from artifacts staging directory to deployment folder / shared location. Only the selected files from the Publish folder are copied to the shared path in this case.BuildStep4

Agent capabilities for unit testing

The General tab in the build definition shows the Demands for the build steps that we’ve added. The same capabilities should exist on the agent that’ll be used to build and run the test steps.

e.g.

  1. Msbuild is used to build the project.
  2. Visualstudio is for other tools that might be required during the build.
  3. vstest is used to run test cases.

Agent.Name is a manually added demand that searches for the Agent by name.

BuildGeneralTab

As per the above screen-shot, the build definition is looking for agent by name “Agent-xxxxx”. This Agent has Visual Studio 2013 installed and some of the capabilities which are automatically discovered.

If any of the Unit Test cases fail during the Build, the build will fail and the remaining steps will not be executed.

Issues faced

Visual Studio 2017 is not supported with TFS 2015 Update 4:

The format of Visual Studio folders under Program Files (x86) and registry settings have changed from Visual Studio 2017 onwards and are automatically discovered as capabilities on the Agent by TFS 2015. Even manually adding such capabilities is not recognized by the TFS Server Build.

Hence, selecting Latest Visual Studio in the drop-down for the Build tasks Visual Studio Build and Visual Studio Test does not work and gives the following errors:

  1. Visual Studio Build:

Visual studio version… not found. 

2. Visual Studio Test:

Unable to determine the location of vstest.console.exe 

To solve these issues:

  1. Use the supported Visual Studio versions 2013 or 2015 on the Build Agents for which the capabilities are automatically discovered while configuring the Agent.
  2. TFS may need to be upgraded to 2017 version.

 

Note: Using a custom build task vstestv2 might work in this scenario using npm install, if the agent version can be upgraded. Current Agent version shipped with the on premise TFS 2015 does not support uploading the custom build task to support the latest test framework. On premise Agent version cannot be upgraded unless TFS is upgraded.

Comments are welcome for improvement!