We’re almost talking about option 2 being a major\/minor release and option 3 being a hotfix like change to the application.<\/p>\n
Let us look at how to implement option 3 using release management.<\/p>\n
Requirements<\/h3>\n
A deployment to an environment might fail when any of the tasks in the deployment workflow fails. In order to get the environment healthy again, we’ll look to execute a rollback script. The script itself would have the following requirement.<\/p>\n
- \n
- Execute the script\u00a0for the environment even when another task has failed.\nWith release management for Team Services, you can look to achieve this using a powershell task and mark it “Always Run”. This way the script shall always get executed, irrespective of the deployment being successful or failed.\nAny of the tasks that are not marked “always run” shall be skipped in case a preceding task failed, but the always run task would be executed.<\/li>\n<\/ul>\n
- \n
- Make selective changes to the environment based on the task that failed in the deployment.\nHaving the script executed always is only half the task. In order to avoid undoing anything that’s not required, we’ll need to know a bit more. First of all, we’ll need to detect if there was a failure at all. In case there was a failure, then what task failed.\nCurrently, there isn’t a way to know about these in the script. We’ll need to query the release from within the script for these. “Rollback powershell” task in the Release Management Utility Tasks <\/a>extension makes this possible.<\/li>\n<\/ul>\n
Implementing rollback script<\/h3>\n
Rollback powershell task helps you understand the history of the current deployment. An environment variable Release_Tasks is set before the rollback powershell script is run.\nIn the script, you’ll need\u00a0to parse the value of Release_Tasks and include the rollback logic accordingly.<\/p>\n
An example to access the task execution information is as follows.<\/p>\n
try\n{<\/p>\n
$jsonobject = ConvertFrom-Json $env:Release_Tasks<\/p>\n
}\ncatch\n{<\/p>\n
Write-Verbose -Verbose “Error parsing Release_Tasks environment variable”\nWrite-Verbose -Verbose $Error<\/p>\n
}<\/p>\n
foreach ($task in $jsonobject | Get-Member -MemberType NoteProperty)\n{<\/p>\n
$taskproperty = $jsonobject.$($task.Name) | ConvertFrom-Json\nWrite-Verbose -Verbose “Task $($taskproperty.Name) with rank $($task.Name) has status $($taskproperty.Status)”\n\/\/ Perform rollback action required in case $task.Name has status failed<\/p>\n
}<\/p>\n
Adding rollback task to deployment workflow<\/h3>\n
- Make selective changes to the environment based on the task that failed in the deployment.\nHaving the script executed always is only half the task. In order to avoid undoing anything that’s not required, we’ll need to know a bit more. First of all, we’ll need to detect if there was a failure at all. In case there was a failure, then what task failed.\nCurrently, there isn’t a way to know about these in the script. We’ll need to query the release from within the script for these. “Rollback powershell” task in the Release Management Utility Tasks <\/a>extension makes this possible.<\/li>\n<\/ul>\n