Release Management – Jasper Gilhuis

July 24, 2017July 24, 2017

Automatically retain a VSTS release

In some environments it can be convenient to retain production releases automatically. Richard Zaat and I worked on this together. Our objective was to retain a release automatically after it has been succesfully enrolled to an environment. To achieve this we wanted to utilize the PowerShell task to minimize the effort.

First we created a demo release pipeline containing one environment. The Release does not do anything and does not have any artifacts. To the environment we only added the PowerShell task.

We have configured to have it use the Preview 2.* version but this works for version 1.* too. The script we have is the following;
$baseurl = $env:SYSTEM_TEAMFOUNDATIONSERVERURI $baseurl += $env:SYSTEM_TEAMPROJECT + "/_apis" $uri = "$baseurl/release/releases/$($env:Release_ReleaseID)?api-version=3.0-preview.2"


$accesstoken = "Bearer $env:System_AccessToken"

Invoke-RestMethod -Uri $uri -Method Patch -ContentType "application/json" -Headers @{Authorization = $accesstoken} -Body "{keepforever:true}"
In the script we construct the URL for VSTS Release Management, together with a ‘template’ to call the Release REST API service, passing the current Release ID. It also constructs the Bearer token to be able to call the REST API authenticated. The last line invokes the contructed REST API call. The call sets the ‘KeepForever‘ attribute of the release. This will exempt it from the release retention policies.

In the release definition the “Agent Phase” needs to be configured to “Allow scripts to access OAuth token”. Listed under ‘Additional Options’ section. This will allow the script to use the $env:System_AccessToken.

The last thing to do is to make sure that the agent account has the “Manage Releases” permissions. This can be done very specifically or for all release definitions.

A few links to usefull resources

VSTS Release API overview
https://www.visualstudio.com/en-us/docs/integrate/api/rm/releases

VSTS Release Retention polocies
https://www.visualstudio.com/en-us/docs/build/concepts/policies/retention#release

Interacting with VSTS and the Rest API’s
https://roadtoalm.com/2017/05/01/only-trigger-a-release-when-the-build-changed/

Enjoy!

October 10, 2016

Adding a DMZ server to the TrustedHosts list

Today I was working with Release Management in an On-Premise TFS 2015 situation where I had to release into server located in the DMZ.

After getting all kinds of things in place, like installing an agent, having shadow accounts setup and having validated i could reach and use the agent to install the required software I came across another issue.

The issue issue was that to be able to run a PowerShell script on the machine, WinRM is used. When running that PowerShell script from the release pipeline it blew up the pipeline with the following error:

“The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config.”

As the error suggests you need to add the server to the local TrustedHosts list. I first checked the current list with the following command:

get-item wsman:\localhost\Client\TrustedHosts

That returned an empty list. And thus I decided to add the current server to the list, which can be done with the following command:

set-item wsman:\localhost\Client\TrustedHosts -value 192.168.XX.XX

The following screen shows the commands in action, actual IP’s are blurred.

dmz_powershell_trustedhosts

When re-running the deployment all was good in the “safe zone”

June 27, 2016

Just published: VSTS Extension Token Comparer

Today I published a new Visual Studio Marketplace extension named “Token Comparer”. In this post I will quickly highlight its features and its usage. In a future post will do and end-to-end scenario so in which you will learn about the creation process as well as the delivery process. But first let’s see the extension.

What does the Token Comparer do?

The Token Comparer can parse specified source files for usage of Tokens and it can compare these against available variables defined in your Release Definition. It will detect and compare the results. Based on the settings you can choose to fail, warn or continue your release.

The tasks will provide you with a summary that will show the findings. The list states the findings.

Configuring the Token Comparer?

In this version I choose to let you define a generic service endpoint to allow safely storing your credentials. Now VSTS has the ability to access an oAuth token this will be changed in a future version.

How to find the Token Comparer Extension

Navigate to your VSTS Team Project. Click the Marketplace icon. Search for “Token Comparer”. Choose to install it to your VSTS account.

Happy Releasing!

February 28, 2014July 17, 2014

Post a TFS Team Room Message from Visual Studio Release Management

This is Part 3 in the series on Release Management + PowerShell + TFS TeamRoom API. In this post I am going to utilize the PowerShell Enabled TFS Team Room API logic from a Release Template in Visual Studio Release Management.

I will not cover a ‘usual’ flow that will release an application based on a Team Foundation Server build, if you like more information on this please check out my post covering that here: Release Management with InRelease

Or you can check out my Curation on Release Management here: Getting Started with Release Mangement

In Part 2 of this series I figured out all the PowerShell commands needed to post a message to the Team Room. Now let’s advance.

Visual Studio Release Management allows for creating custom tools. To create a Tool a Custom PowerShell Script can be used, so let’s make a script that can post the message. You can use the PowerShell ISE Editor to create this script.

A little clarification on the script. It has two parameters, TeamRoomMessage and TeamRoomName. I choose not to pass all the TFS configuration to the script, but if you want you can 🙂

After declaring the parameters, the module (Wrapper to the Team Room API) is imported. Then variables are set and the call to the Team Room is made passing the received parameters.

Creating the tool in Visual Studio Release Management is fairly easy. Most important part is adding the PowerShell script as a resource. On the Execution section we specify that the tool is a PowerShell command.

Our script needs two parameters and those need to be passed as arguments to the script. Mind that the parameters are qouted otherwise spaces in the message might break the script.

Having created the tool we need to create an Action to be able to add this to the Release Template. The creation of the Action is quite similar to the creation of the tool.

Having the Tool and the Action ready we can continue to create a very simple Release Path to post a message. The Release Path is using an existing stage (Development) and an existing environment (Development Environment). Acceptance and validation are both set to be automatic. This way no manual actions are required.

Now that we have a Release Path available, we need to create a Release Template. On the Deployment Sequence we drag our target server. Next in to Toolbox we browse to the Custom Section. In the section we can find our Custom Action. Drag this action to the Server surface. It lists the two parameters that our action needs, which now can be provided.

After saving, on the top menu there is the possibility to create a “New Release”, provide it a unique name and our Release Template is pre-selected.

Let go and start the release! After starting the release you will see the Release Progress. As acceptance was set to be automatic, that step is automatically passed. Next the Deploy step is executed, status is Pending.

After a little waiting (posting the message doesn’t take that long) this will transfer to Done.

For the Deploy step there are details available. You can review these by clicking the ‘…’ button. The Deployment Log screen will be shown.

Through the View Log button we can see the log that is created during our ‘Add TeamRoomMessage’ action. The log message contains the output generated in our PowerShell Script. As we can see below it says our message is successfully posted!

The only place to find out if that’s true is to head over to our Team Room and see for our self! As expected the message is there!

As mentioned in the previous posts I promised to all the source code required for this complete series. You can download the source for this here: Release Management – Distribution.zip

Please note that this code was written for demo purposes only and is not intended to run on your production environment.

If you have any questions or remarks please feel free to leave a comment or contact me on twitter @jaspergilhuis

February 12, 2014July 17, 2014

Blog Post Series announcement on Release Management + PowerShell + TFS TeamRoom API

In a new series of posts I will be getting more out of the combination of Visual Studio Release Management + PowerShell + TFS TeamRoom API. The series will consist out of 3 posts that wrap it all together.

First post will come shortly! Stay tuned!

Update 1: Posted part one on 18 februari 2014
Update 2: Posted part two on 23 februari 2014
Update 3: Posted part three on 28 februari 2014

December 18, 2013March 31, 2014

Visual Studio Release Management on Curah!

To keep track of things I have created a Curation for Release Management. This can be found here http://curah.microsoft.com/42805/getting-started-with-release-management. I try to keep it up to date to have it as a handy reference.

December 6, 2013July 17, 2014

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!

October 14, 2013July 17, 2014

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 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/