Release Management and PowerShell

A few weeks ago I wrote a (long) post on InRelease, since it has been released on November 13th, it is now officially called Release Management.

Release Management comes packed with useful Tools, Actions and the ability to create Components. With these items you can really shape your ReleasePath to your needs. But it could happen that there is something you want to achieve that is unavailable.

While there are several other options available in preparing your Web solution for deployment with Release Management, I recommend reading Colin Dembosky’s post on Web Deploy and Release Mangement – the proper way, I want to explore PowerShell options. Another option would be using the Tokonization functionality (not checked this against the Release Management release).

The following steps will guide you through the process on calling a custom PowerShell action from your Release Template.

Disclaimer: I am a PowerShell newbie, so there probably are more powerful or optimized scripts possible…

1. Lets create a PowerShell Script for your desired actions. Using the PowerShell ISE Editor will help you in getting the syntax right.

2. Lets create a very basis script first. Containing all hard-coded raw materials. Test the script to see if you got all the syntax and desired outcome. In this case, ‘BlogEngineData’ is replaced by ‘BlogEngineDEV’.





3. Now we have a functional script, lets add some parameters, so we enable reuse of the script. Validate the script by executing it.




4. Now open [Release Mangement], navigate to [Inventory] and then [Tools]. Then create a new [Tool]. The tool is capable of executing the powershell script, that will be added as a resource.








Notice that in the [Arguments] options we use the Release Management parameter syntax ‘__Parameter__’ (yes that is two! underscores to start and end with). All recognized parameters are listed in the Parameters section. For our script that is four.

5. Make sure you upload the PowerShell script as a Resource. Find my sample PowerShell Script here

6. To be able to use a [Tool] you need to create an [Action], so navigate to the [Actions] section within the [Inventory] and create a new [Action]. Follow the options below and you will be OK.

Tip: Create a Category for your ‘Custom’ actions. This will help you in adding them to the Release Template.








7. Now we have a new Tool and Action we are ready to use it on our Release Template. Navigate to [Configure Apps], [Release Templates] and open a template. Find your ‘Custom’ Action, drag it to the canvas, and fill all the properties.









8. Repeat this for all your Environments / Templates.

The Release Template is now ready to be used! With this example I hope to show the potential of using a custom PowerShell script to extend the Release Management Toolbox.

Happy Releasing!

Release Management with InRelease

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:

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

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.

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 consist of Release Input (read: TFS Build Output) and Tools.

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:

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 and through The Visual Studio blog on MSDN:

InRelease for Visual Studio 2013

Continuous Deployment with Microsoft Visual Studio:

Improving Developer Productivity and Software Quality with Microsoft Visual Studio Application Lifecycle Tools:

What’s New in the Visual Studio 2013 IDE:

InRelease Forums

Visual Studio ALM Rangers Branching and Merging Guidance

Use Advanced search when TFS does not find text in work items

The Road to ALM

Alert: Editing the TFS Collection database is tricky and should be done with extreme care!!

Recently I migrated a whole bunch of work items from a StarTeam repository. To keep some of the initial history, I added a some summary in the description field of the work item.

This looked something like this:

  • Originally Created On: 20-07-2009 10:13:21
  • Created By: StarTeam Server Administrator
  • ExternalReference: 123456
  • Last Build Tested:
  • Starteam ID: 17525

All worked great but then…When searching for the text “” in Web Access my Query showed no results.



The query that was constructed looked impressive though. Obviously it splits on the “.” sign


When I tried to search including quotes (“”), it did not show any results as well. Hmm.Frustrating.


After some digging and with help of some guys at Microsoft (thanks Grant, Ewald and Hakan!), I found interesting thing.

The search over the text and…

View original post 380 more words

TFSSecurity to the rescue!

Recently I wanted to give everyone who has access to TFS [Read] permissions to a specific folder in Source Control. When going through the Security settings I came across an interesting group [Project Collection Valid Users]. It contains all the team projects valid users. Sounds just like what i need.

I fired up Source Control Explorer from VS 2012 and navigated to the Special folder under the TFS_Rights Team Project. I clicked [Advanced/Security] from the context menu. That fired up the Web Access client for the Team Project. I navigated to the Readers group to see if there was an option to add the [Project Collection Valid Users] group to it.


Unfortunately that group is not available to add through the user interface.

So what to do next? Create a new TFS group and add all the users and keep it up to date?

Possible but i there might be a way out….. TFSSecurity to the rescue! Running the following  command will actually add [Project Collection Valid Users] to the Specific folder. 

tfssecurity /a+ VersionControlItems “$/TFS_Rights/Special Folder/” Read “[DefaultCollection]\Project Collection Valid Users” ALLOW /collection:

Executing this command will give you confirmation that it was successful.


Now lets see if the interface acutally knows about it:


Voila! It’s all there! Mission accomplished!

Sprint Progress in Color

Some time ago, to be precise may 13th 2011, my collegue René van Osnabrugge posted the initial version of the Excel Template on “Managing your sprint backlog easier with Excel”.

Recently I have used it again and found time to provide some minor polishing!
Please visit the original post for directions on using it.

An updated version of the Excel Template can be found Progress in Color – Template

The file has been updated again. Please save the file as an .XLSM

ALM Summit 3 – Recommended Books

Last week i attended the ALM Summit 3 in Seattle together with @MarkvandenBerg.
A big thanks to @DeltaNBV and @renevo for enabling that!

During the very interesting sessions of this summit allot of book recommendations where done so i decided to put these in the list below (no particular order). I may have missed some, so contact me if you want one added 🙂

The Scrum Field Guide, Mitch Lacey

Switch, Chip Heath & Dan Heath

Testing for Continuous Delivery with Visual Studio 2012

The Principles of Product Development Flow, Donald G. Reinertsen

Agile Software Requirements, Dean Leffingwell

Leadership The Hard Way, Dov Frohman & Robert Howard

Yes to the Mess, Frank Barrett

Negotiating with Emotion, Kimberlyn Leary

The Generals, Thomas E. Ricks

Virtuosity, Diana & Willem Larsen

Liftoff, Diana Larsen

Agile Retrospectives: Making Good Teams Great, Diana Larsen

Project Retrospectives: A Handbook for Team Reviews, Norman L. Kerth

Simple Rules: A Radical Inquiry Into Self, Holladay & Tytel

Bridiging the Communication Gap, Gojko Adzic

Specification By Example, Gojko Adzic

Explore It!, Elisabeth Hendrickson

Exploratory Software Testing, James Whittaker

Continuous Delivery, Jez Humble

Theory of the Firm, Jensen and Meckling

Books by Jack Welch

Lean IT, Orzen and Bell

The Lean Startup, Eric Ries

Lean UX: Applying Lean Principles to Improve User Experience, Jeff Gothelf

The Principles of Product Development Flow, Donald G. Reinertsen

Toyota Kata, Mike Rother

Drive: The Surprising Truth About What Motivates Us, Daniel H. Pink

The New Kingmakers, Stephen O’Grady

UML Applied: A .NET Perspective, Martin L. Shoemaker

Agile Software Engineering with Visual Studio: From Concept to Continuous Feedback, Sam Guckenheimer & Neno Loje

Software Engineering with Microsoft Visual Studio Team System, Sam Guckenheimer & Juan J. Perez

Visual Studio Team Foundation Server 2012: Adopting Agile Software Practices: From Backlog to Continuous Feedback, Sam Guckenheimer & Neno Loje

The Four Steps to the Epiphany: Successful Strategies for Products that Win, Steven Gary Blank

Running Lean: Iterate from Plan A to a Plan That Works, Ash Maurya

Antifragile: Things That Gain from Disorder, Nassim Nicholas Taleb

Crisis an Innovation, Charlota Perez

Shating Strategy in a World of Constant Disruption