October 2013 – Jasper Gilhuis

In this post I will highlight the latest addition to the Visual Studio product suite, InRelease. This Release Management tool, which was recently acquired by Microsoft, is meant for bridging the gap between Development and Operations by providing a clear, repeatable, automated deployment procedure.

This post has been written with the knowledge that in a few weeks InRelease will be integrated in the VS2013 suite. VS2013 will globally launch on November 13^th. I will update this post accordingly when it is released.

Introducing a new tool is difficult, I will first cover the surroundings, introduce related topics and terminology and will then go into more details on the Release Management tool itself by doing a walkthrough.

Branching Strategy

Most Development teams will use some form of branching strategy, in my ALM consultancy job I frequently implement the following branching strategy. See the Visual Studio ALM Rangers Branching and Merging Guide for more guidance: http://vsarbranchingguide.codeplex.com/

Figure 1 Branching Strategy

Most development activities takes place on the DEV branch. A scheduled nightly build could be triggered to package the new version of the application as a start for deployment. The MAIN branch is used to compose new releases of the software. The developers regularly merge from DEV to MAIN to create a new release. The Release branches are created for enabling updates (hotfixes) during ongoing development. Utilizing TFS builds packages can be created from this branch too.

Deployment Environments and Scenarios

Where branching strategies are used to keep different versions of the software isolated, environments are used to keep running software isolated. Environments are used to make the software runnable for different roles in order to test, validate or trial run the software.

In order to get the software on an environment you will need a Deployment scenario. A deployment scenario describes how and where the software will be installed. As a result, a Deployment Scenario can affect different server environments. And, in their turn, server environments can consist of multiple machines and stages. Most companies will have a set of environments to support their application lifecycle. Below I have added a table identifying ‘my’ view, adding a brief description providing a little context.

Environment	Description
Development	A central development environment that is mainly used to accommodate Continuous Integration. Software deployed here originates from the DEV branch.
Test	A central stable test environment for testing purposes. Software also originates from the DEV branch.
Integration	The integration environment that can be used to run a first version of a release with all code from all teams integrated. Testers can run their end-to-end tests on this environment. The software originates from the MAIN branch.
Acceptance	When accepted on the integration environment, the software is deployed to acceptance. Typically stakeholders, product owners and sometimes customers validate the software on this environment.
Production	The environment where the software is running in production.

Having introduced the environments, we could think of a scenario where code is being developed and checked in into source control, a Team Foundation Server build packages the software and will trigger a deployment scenario to place the built software on an environment.

This is where traditionally development and operations work together to get software released.

In many organizations, deployments are done by the IT Operations department. They want to validate the bits that will be deployed. On the other hand specific roles want to approve the files that are deployed. Adding acceptance, validation and approval steps to the deployment scenario would take away unnecessary delay and result in the following Release Management workflow.

Figure 2 Release Management workflow example

In the above workflow we can imagine Continuous Integration on the DEV branch towards a development environment. When successfully deployed and validated, testers are able to update their test environment accordingly when they are ready for it.

Using the MAIN branch for releases towards production would require a new build triggering a new deployment scenario with all its accompanying steps. More details will be provided in the walkthrough.

So what do we need to support this kind of operations?

System Topology

Enabling this kind of scenarios requires us to have the following items available. A Team Foundation Server and a Build server to start with. Next we need an InRelease Client application, installed on one or more clients, and we need to have an InRelease Server installed. In this post I will not cover installation and configuration scenarios. See the section Links & References for more information.

Figure 3 System Topology

The environment for the application consists of a webserver and a database server. All servers subject to deployments by InRelease are required to have an InRelease Deployer installed to be able to communicate with the InRelease Server. Besides the technicalities we also need to users / groups for approval en validation of the deployment process.

Release Management Concepts

InRelease introduces a new set of concepts and terminology that (may) require some introduction, so let’s start by quickly introducing the most important ones;

Release Template
A release created by defining a Release Template which consists of a Release Path, Workflow and TFS Build output, while not required it is the most likely scenario to be TFS Build driven.

Figure 4 Release Template Concept

Release Path
With a Release Path one or more stages of the deployment are targeted. The stages represent an environment e.g. Development, Test, Integration, Acceptance, Production.

Figure 5 Release Path concept

Environment
A server that can be used to deploy to, this server will have InRelease Deployer installed. An environment van consist of multiple servers.

Approval Workflow
The approval workflow is used to inform users / groups on activities taken place during the release.

Workflow
The deployment workflow consists of a Deployment Sequence, per stage. This is a workflow defined out of Components and Actions. The workflow also has context of a build.

Figure 6 Workflow Concept

Components
Components consist of Release Input (read: TFS Build Output) and Tools.

Actions
Actions can also make use of tools. A tool could be a batch script that needs execution. It can also have parameters.

TFS Build Server
The TFS Build server does ‘not’ require changes. InRelease provides a new build template that has customizations added that allow communication with the InRelease Server. Some parameters are provided to tune the communication. The most important parameter is “Release Build”. When set to True, the build will contact / trigger InRelease when the build is successful.

Tying the parts together

Now that we have identified all pieces of the puzzle, let’s put it together. For the sake of simplicity I will minimize the scope to a deployment towards development and test environment.

Figure 7 Simplified deployment scenario

To be able to support this scenario I have configured the following items:

Release Path
The Release Path consists of two stages, resembling the Development and Test environment listed above.

Figure 8 InRelease Release Path definition containing two stages, Development and Test

The ‘Acceptance Step’ for deployment to the development stage is set to be automatic. This removes the need to accept the physical deployment, which is just what we want when a TFS Build triggers a deployment. All configured developers (in a group) will be notified of each step.

Both the Development and Test stage have a corresponding environment consisting of 1 server (handles both web and database).

Release Template
A Release Template is created and configured to use the previously created Release Path. It also is configured to respond to calls from TFS Build Server.

Figure 9 Release Template properties show template to be responding to TFS Builds

The Release Template contains the actual Deployment workflow;

Figure 10 Deployment Scenario overview

The Deployment Sequence consists of creating an application pool, creating a website in IIS, placing the content directory (from TFS Build Output) and Starting the website. Simultaneously a backup of the existing database is created, current DB is dropped, new is created and scripts are executed against it. Though this is still a very happy path scenario it shows to what extend you can run actions. Several other flow / process controlling options are available, for instance Rollback.

Having done all the shaping / defining of the deployment scenario it’s time to ‘see’ it in action.

Release Management Walkthrough

On any given day the Development team adds new code to the DEV branch. The scheduled nightly build runs successfully and then triggers the InRelease. InRelease fires the Release Path configured to respond to this build.

First step is all developers receive an email notification stating Deployment has been accepted, see Figure 11, indicator 1. Then a second notification is sent, that actual deployment is started, Figure 11, indicator 2. This will execute the actual deployment sequence. After deployment an email is sent to ask the Development Group for validation, Figure 11 indicator 3.

Figure 11 First Email notifications

In the validation email a link is provided to the web interface providing insight in the steps executed, see Figure 12 indicator 2, as well as the pending requests assigned to the user, see Figure 12 indicator 1.

Figure 12 Approval of deployment

When looking at the deployment details, we can see that deployment towards Development has been accepted automatically and deployment has been successfully installed, and is now awaiting validation.

Figure 13 Workflow visualisation

After validation, see Figure 12 indicator 3, an Approval requests will be sent out.

Approvers receive the request to approve the deployment, see Figure 14. Approvers are able to approve or reject this deployment, resulting in allowing additional steps in the release path. A feedback message can be provided optionally.

Figure 14 Final approval of deployment to the stage

When approved, the Testers, as configured in the Release Path, receive an email notification. They are asked to accept deployment to their Test environment. They can choose to accept or decline this deployment, providing testers with the flexibility to not automatically work against a new environment. The email request for this is shown in Figure 15.

Figure 15 Deployment Acceptance email

When the Testers accept the deployment an email notification is sent that deployment is started. After deployment is successful a notification is sent to the Testers to validate the deployment.

When validation is approved final approval is requested from the testers, which terminates the deployment workflow.

Within InRelease an overview of all activities, including details on the deployment, is also provided.

Figure 16 Track Releases

Wrap up

Having played with the bits it seems to me that the tool really allows to take the next step into deployment scenarios! Can’t wait till November 13^th Launch! Keep an eye on this site for more news: http://events.visualstudio.com/