Visual Studio Release Management

Do we need to manage software releases/deployments in a well planned methodology? Do we need to track the details of the releases/deployments? Do we need to have a proper rollback strategy if something goes wrong in a deployment to production? I could keep asking more and more questions like this related to the software release management, and always the answer would be “YES”.
So what are our options, in terms of Microsoft ALM set of tools. TFS Lab environments can be used, but can we use it for production releases automation? Yes, if the client is willing to provide trusted access to production environment, via TFS Lab environments. But in most cases client would not like this. To add more pain to this Lab environments deployments would over utilize the build servers, with long running deployments. The solution for all this pain is addressed well in, new Visual Studio 2013 Release Management.
First we need to understand “Why” we need to manage releases. This post in NorthWest Cadence provides great insight.
There are three major components in VS 2013 Release Management.
1. Release Management Server.
Set of windows and web services that act as the core part of the release management. There is a portal providing approval capability to the release check points, without having to install Release Management Client or Visual Studio.
2. Release Management Client.
Windows Presentation Foundation (WPF) application provide the interface to manage the releases and configurations of release management.
3. Deployment Agent
Resides in target servers in the environment and performs the deployment actions such as installing, uninstalling, configuration etc. of software components.
Each of above performs its own duty, and resides in different computers. Together they make deployment automation a possibility with all the visibility and traceability expected in proper Application Lifecycle Management process.
The following diagram extracted from VS 2013 Release Management Installation Guide provides overview of “How it works”.



Even though above picture shows TFS, it is not mandatory to have TFS for VS Release Management to work. If the TFS is available can be tightly integrated with it. If not it could obtain payload for the deployment from any accessible drop locations (UNC path). This means the deployment could be even something not developed with .Net .
Below diagram from VS 2013 Release Management Installation Guide  explains communication between components of release management.



The most important thing here is the Deployment Agent is downloading the components for deployment as a pull request. Nothing is pushed from Release Management Server to Deployment Agent. This enables the possibility of Release Management Server not requiring access to Production environments. Deployment Agent notify Release Management Server it’s availability via heartbeat.

Let’s start our journey to explore Visual Studio Release Management by setting up an environment step by step, with my series of blog posts in next few weeks.
1. Setup Release Management Server.
2. Setup Release Management Client.
3. Setup Deployment Agent.
4. Configure SMTP.
5. Configure TFS Connection
6. Setup Stage Types.
7. Setup Servers & Environments.
8. Setup Release Path.
9. Demo Release Template - Part 1.
10. Demo Release Template - Part 2.

Awesome Improvements in Visual Studio Online

VS Online is added with few great improvements. My guess these will be available with TFS 2013.3 for on premises TFS. Still had no chance to have a look at 2013.3 RC :( .

Hiding work in progress on the backlog
Full Screen on the backlog and boards
Move to position on the backlog
REST APIs and service hook support for pull requests

Have a look at release note of VS online for more detalis

11. Create a Release Build - Setup Virtual Environment for TFS 2013 - Using Virtualbox

In this step of ALM demo environment (Virtual Environment for TFS 2013), I am going to explain how to create a Release Build to build the website we have created in “Create a Simple Application and a CI Build”.
First step is to setup a drop location for our Virtual Environment for TFS 2013. For this we will use the build server we created in “Setup a Build Server”.



We have to give permission to TFS Build Service account (we have setup in “Setup a Build Server”), full control for the drop folder, in order to create build outputs



Let’s share this folder for read access for everyone.




Verify access from the development machine.


 

Now we are going to clone the CI Build which was setup in “Create a Simple Application and a CI Build”.



Let’s rename the build definition.



Change the trigger of this build to manual.



Set the build drop location.



We are going to keep all successful builds (We need to keep these builds outputs and details as long as required and manually archive whenever necessary).



We are now done with the build definition. (We have changed nothing in the process tab. It is as same as the CI build setup in “Create a Simple Application and a CI Build”.)



Let’s queue a release build.


  

Build starts to run.

Once the build is done, we can see the output in the build drop location.


 

We can find the site created in “Create a Simple Application and a CI Build”, published in to BuildDrop\_PublishedWebsites.
I will conclude the series Virtual Environment for TFS 2013 with this post. Do not worry, as promised when I started this series of posts, I will continue to explain VS 2013 Release Management as a new series using Virtual Environment for TFS 2013.

10. Create a Simple Application and a CI Build - Setup Virtual Environment for TFS 2013 - Using Virtualbox

Now we are ready with TFS, Build Server and Development machine in our ALM demo environment (Virtual Environment for TFS 2013), and it is good time to create simple application and a CI build for it. If you wonder what is a CI Build and why we need it refer my post “Why CI build”.
Let’s create very simple Asp.Net Web Forms application first. Here I do nothing but use the template to create a simple app.

First a VS Solution.



Next add a ASP.Net Web Forms Application.


 

Now we have a basic Asp.Net Forms Application up and running.


 

Let’s check in this to TFS.


  

Now we have a simple application checked in to TFS.



Our next goal is to set up a CI Build, which builds for each changeset we check in. A new build definition can be created by navigating to Builds from Team Explorer Home, and clicking on New Build Definition.


 

Build name specified as “DemoWS.CI”.



In the trigger we have to set as Continuous Integration to make the build trigger for every check in.



Source settings we have to specify the correct source mapping.

We do not want to create any output from this CI build. We are just making sure our code is in a valid state and compile without errors.

In the Process tab of build definition we specify solution to build and we are setting build agent tags to correctly locate the build agent.



We are setting at least a build agent with VS2013 available should be located when the build is triggered.
 

 
 

Configuration to build we are selecting in this demo is Release and Any CPU.





We do not want to keep all successful builds in a CI build, since this is just a verification of latest source state of success compilation. 



Once we save our build definition is ready.



We can queue a test build by right clicking on the build definition and click on Queue New Build.

 

Build is just started

Double click on this will open detail view.



Our CI build is done. (Ignore the time taken to build, my build server is having only 512MB RAM and TFS server only 2 GB of RAM, it will be much faster in a virtual/physical environment with more resources :))



Now let’s do a code change and check in to see if a new build triggers. Assume I have a bug to fix :)



So let’s do the fix.



We do the change



Then check in while resolving/closing the task.





Check in has triggered a build and it is done.



We can see our work items (task and Bug) associated correctly to the build.

 

The task is set to closed automatically.



We can resolve the Bug now.



Next I will explain how to create a release build with a build out put.