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 13th. 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 13th Launch! Keep an eye on this site for more news: http://events.visualstudio.com/
Links & References
Information in this post are based on first hand experience, background reading and watching video’s.
Information on Visual Studio can be found on the Visual Studio Homepage http://www.microsoft.com/visualstudio/eng#visual-studio-2013 and through The Visual Studio blog on MSDN: http://blogs.msdn.com/b/visualstudio/
InRelease for Visual Studio 2013 http://www.microsoft.com/visualstudio/inrelease/inrelease-2013-preview/
Continuous Deployment with Microsoft Visual Studio: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/DEV-B329#fbid=lVHf3WshuaQ
Improving Developer Productivity and Software Quality with Microsoft Visual Studio Application Lifecycle Tools: http://channel9.msdn.com/Events/TechEd/Europe/2013/DEV-B321#fbid=I7qTcslP8Ax
What’s New in the Visual Studio 2013 IDE: http://channel9.msdn.com/Events/Build/2013/3-339
InRelease Forums http://support.inreleasesoftware.com/forums
Visual Studio ALM Rangers Branching and Merging Guidance http://vsarbranchingguide.codeplex.com/
![clip_image002[5]](http://osnabrugge.files.wordpress.com/2013/10/clip_image0025.jpg "clip_image002[5]")
![clip_image002[7]](http://osnabrugge.files.wordpress.com/2013/10/clip_image0027.jpg "clip_image002[7]")
Jasper Gilhuis 