Release Management with Team Foundation Server 2015

Introduction

In this article I intend to follow on from my previous articles on using Team Foundation Services (TFS) 2015 and focus on creating releases and deployments. My previous articles can be found below. If you haven't already read them then feel free to do so before continuing with this article.

• Introduction to Team Foundation Services 2015
• Unit Testing with Team Foundation Services 2015

The aim of this article is to follow on from my previous articles which gave you an introduction to setting up and configuring Team Foundation Services (TFS) 2015 and then adding unit tests to ensure that your code is correct. The next logical step would be to deploy your software once it has been built and tested.

For the purposes of this article I will configure a very simple release and deployment strategy that auto-releases each new build into your development testing environment. You obviously wouldn't want this for a QA or production environment, but more on that later. So whereas in my first two articles we created a Continuous Integration (CI) pipeline, in this article we will create a Continuous Delivery (CD) pipeline by continuously deploying our software to our development testing environment.

Just to be clear on terminology, what I am specifically referring to when I use the term development testing environment is a testing environment for the sole and exclusive testing purposes of the development team. It is not intended for any other person(s).

Background

It is assumed that the reader has some basic knowledge of Team Foundation Services and of the basic principles of building and releasing software. Reading my previous articles would help with this greatly.

Releases and Deployments

Before we get down to creating our releases and deployments, we firstly need to understand what these are. Another term we will also need to understand is environment.

• Release - refers to the set of build artefacts that are created after a build. They reside within TFS so are not at this stage actually deployed anywhere. Therefore they represent candidate deployments i.e. a complete set of build artefacts that could be deployed if necessary.
• Environment - refers to the endpoint of where we wish our release to be deployed e.g. QA environment, Production environment, Development environment etc. These can be endpoints located on the local network and / or in the cloud e.g. an Azure instance.
• Deployment - refers to the act of pushing the release to the specified environment or endpoint as necessary. In our example our environment will be to a development testing environment.

Release Management in TFS therefore consists of two tasks:

1. Create a release
2. Deploy the release to a specified environment

Creating a Release

By clicking the RELEASE menu item from the top menu of your TFS dashboard you open the Release Explorer dashboard. It is from here where you will create your release and deployment for the currently selected project. You will be presented with a list of any currently configured Release Definitions as well as the releases created from those Release Definitions.

To begin with click on the plus (+) sign above the Release Definitions

You will be presented with a list of deployment templates to choose from. For the purposes of this article I will select the Empty template, but feel free to select any of the other templates as necessary.

Click the OK button to proceed. You will now be presented with an empty Release Definition and associated Environment as in the screenshot below.

1. Give your Release Definition a meaningful name in the textbox provided e.g. Development Release
2. 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. DEVELOPMENT, QA, PRODUCTION.
   • Click on the ellipsis next to the environment name and select Deployment conditions...

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 artefacts will need to be undertaken manually with no automation
• After release creation - this will deploy the build artefacts 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.

For the purposes of this article I will select the second option After release creation as I am deploying the build artefacts immediately to our development testing environment.

Just to repeat what I said earlier, a Release is not the same thing as a Deployment. A Release is a complete set of build artefacts that can be deployed to the specified environment. Whereas a Deployment is the actual act of pushing the build artefacts to the specified environment.

So in the example above, I have configured the deployment of the build artefacts to the development testing environment every time a release is created i.e. every time a build occurs (which is triggered by a code check-in), a Release is created and this is deployed to the development testing environment.

Although I am not setting up any Approvers for this particular article, it is worth exploring the Approvals tab. This is where you can configure who has the authority to approve or reject deployments to particular environments. For example you may want to seek the approval of the Software and / or Testing Manager or the Change Advisory Board if you are implementing a framework such as ITIL before a deployment.

Once we have defined the environment, we next need to add the necessary task(s) which will be invoked when we want to deploy our build artefacts to the specified environment. You can deploy your build artefacts to a server / virtual machine on the local network or to the cloud e.g. to an Azure instance. For the purposes of this article and to keep things simple I will deploy the build artefacts to a server on the local network. However, it is highly recommended that you investigate using the cloud for your testing environments.

Click on the Add tasks button to create our deployment task i.e. the action that we want to happen when we invoke a deployment.

Select Windows Machine File Copy, click the Add button then click Close. Enter the necessary details as appropriate. An example screenshot is given below.

Just to recap. Every time we trigger a build we create a Release. This is then automatically deployed to the development testing environment using the details we supplied as part of the deployment task above.

So far we have created our deployments automatically each time a release is created. Whilst this is great for our development Continuous Delivery pipeline, it's probably not something we want to do in our testing or production environments. For those environments we want to deploy manually on an ad hoc / scheduled basis rather than automatically.

Creating a Manual Deployment

To do this we repeat the previous steps for Creating a Release but make a few subtle changes.

Click the OK button to proceed. You will now be presented with an empty Release Definition and associated Environment as in the screenshot below. Give it a meaningful name e.g. PRODUCTION.

When we configure our environment we use the No automated deployment option whereas previously we selected the After release creation option.

As we are now deploying to a production environment, it's a good idea to define approvers who have the authority to approve the deployment into a production environment.

When we define our release task we enter the details of our production environment whereas previously we entered details of the development testing environment.

So that's the Release Definition for our production environment defined. The last steps now are:

1. Create a release using the production environment Release Definition we have just defined
2. Deploy that release to the production environment

Select the PRODUCTION Release Definition and click on Release and Create Release.

Enter a meaningful description as this will appear in the list of releases when complete. Select the build you want to use as the basis for the release from the Artifacts dropdown. Presumably this will be the latest build but choose whichever build as necessary. Click on the Create button to proceed and create the new release.

The next step is to deploy the release. This will deploy the release to the PRODUCTION environment defined earlier. We can see in the screenshot below that the bar under the Environments column is grey. This will change to green once the release has been deployed.

Double click on the release to open the deployment details page. From here we can finally deploy our release. Click on the Deploy dropdown and select the PRODUCTION environment we defined earlier.

We are now finally able to deploy our release by clicking on the Deploy button. This may take a few minutes depending on the size of the release and the endpoint to where you are deploying the release (your network latency if deploying to the local network or your internet speed if deploying to the cloud for example).

Assuming everything went without error you should see that the deployment status has turned green indicating that the release has been successfully deployed.

Summary

That's all there is to it. At its core the process is pretty straight forward. My suggestion would be to get the basics working first, and then add further steps later as needed. For example, adding approvers to your production deployments is a good idea. It's worth spending time looking around the various options that are available to see if you can make use of any of them in your own development pipeline. Feel free to leave a comment if you would like me to further elaborate on anything within this article.