0 comments
Various 
Since the beginning of time (well since we have computers. 
) teams are using different environments to install and test their applications before actually putting them into production.
In the last couple of years, teams are focusing more and more on automating this process. With the release of Team Foundation Server 2013, Microsoft provides a tool called Microsoft Release Management to automate the deployment process across multiple environments.
Note: If you want more information on how Microsoft Release Management works, I recently did a talk on the how to use Microsoft Release Management in combination with Windows PowerShell Desired State Configuration to automate an deployment on DotNetFlix. You can have a look at the video here.
During your automated deployment process it could happen that your deployment fails for whatever reason. In some cases you might be able to fix the problem. At that point you probably want to restart the process or continue the automated deployment process at the failed step.
Microsoft Release Management provides functionality to retry a failed deployment or restart the complete deployment process at a specific stage. For a Rejected release, the buttons: ‘Retry Failed Deployment’ and ‘Restart Stage’ are available to do just that:
However, it turns out these buttons are not always available for everyone.
How Microsoft Release Management works
In Microsoft Release Management you need to define the environments on which to install your application and the process of how to install your application. This is done by defining a Release Path and a Release Template.
The Release-Path describes the different Stages (environments like development, test, production, etc.) the application needs to go through before it is deployed into production.
A Release Template describes how to deploy the application in each of the Stages as defined in the Release Path.
When a deployment is triggered a Release is created. For each Stage in the Release, the same high-level steps are executed. The deployment process looks pretty much like this:
For each stage the same 5 high-level steps are executed. First the deployment must be accepted. Next some pre-deployment activities are performed. Then the deployment process, as you defined it, is executed. After that the deployment is validated. Finally, if you configured it that way, the release is approved by 1 or more persons.
When the Release-Path is configured, you need to specify for each of the high-level steps who owns that step in that stage:
It is possible to specify a single user or group that owns the deployment step. Only for the Approval Step can you specify more than 1 user or group.
Note: The Predeploy and Deploy steps as shown in the Release are configured as a single step (Deployment Step) in the Release Path.
In the Release overview the owner is displayed for each step that is executed.
If a Release failed, the status of the high-level step that actually failed will be Rejected. If you are the owner of that failed step, you will be able to retry the failed deployment or restart the Stage in which the failure occurred. If you are not the owner of the failed step, the buttons: ‘Retry Failed Deployment’ and ‘Restart Stage’ will not be available to you.
Note 1: If you are the owner of a step in any of the configured stages, you will see the retry-buttons regardless of whether you are owner of that step in that specific stage.
Note 2: If you are added as an owner to a step you previously did not own, you won’t see the retry-buttons for releases that already have been executed.
Permission: Can Release
One of the permission that can be granted on a Release Template, is the permission to start a release:
This permission controls whether you are able to start a Release for the given Release Template. However, this permission doesn’t control if you can retry a failed deployment or restart a stage.
Check to see if you should get the retry-buttons
To check which users should be able to retry a failed release or restart a stage, I wrote a SQL script that can be executed against the Microsoft Release Management database.
DECLARE @ReleaseTemplateName VARCHAR(255)
SET @ReleaseTemplateName = ‘<YOUR RELEASE TEMPLATE NAME HERE>’
SELECT U.Id, U.DisplayName, U.UserName, SG.Name
FROM SecurityGroup_User SGU
INNER JOIN [User] U ON (U.Id = SGU.UserId)
INNER JOIN SecurityGroup SG ON (SG.Id = SGU.SecurityGroupId)
WHERE SecurityGroupId IN
(
SELECT Id
FROM SecurityGroup
WHERE Id IN
(
SELECT ApproverGroupId
FROM StageStep
WHERE StageId IN
(
SELECT S.Id
FROM Stage S
INNER JOIN StageType ST ON (ST.Id = s.StageTypeId)
WHERE S.ReleasePathId IN
(
SELECT ReleasePathId
FROM ApplicationVersion
WHERE Name = @ReleaseTemplateName
)
AND S.IsDeleted = 0
)
AND StageStepTypeId IN
(
SELECT Id
FROM StageStepType
WHERE Name = ‘Deploy’
)
)
)