aseemb's blog

How can I view the release history records programmatically?

Aseem Bansal [MSFT] — Wed, 27 Feb 2019 08:14:15 GMT

One of the user asked how he can access the comment that he entered while starting the environment programmatically. These comment can be seen in the history records of the Release UI as shown below. But to access them via APIs, we have not documented our release revision APIs publicly but will do so shortly. Till then you can use the below API to get the same history records.


https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/releases/{releaseId}/history?api-version=5.0-preview

For the above release image, the equivalent request/response are: - Request


  https://vsrm.dev.azure.com/mseng/AzureDevops/_apis/release/releases/8409800/history?api-version=5.0-preview

Response


{
  "count": 8,
  "value": [
    {
      "releaseId": 8409800,
      "changedDate": "2019-02-26T23:13:22.893Z",
      "changeType": "Start",
      "changeDetails": "Started 'TFS - Prod Config Change 8726'",
      "comment": "Set up tfs-uks-1 for AX Everywhere & shadow testing"
    },
    {
      "releaseId": 8409800,
      "changedDate": "2019-02-26T23:13:27.027Z",
      "changeType": "Deploy",
      "changeDetails": "Queued deployment on 'Single ScaleUnit'",
      "comment": ""
    },
    {
      "releaseId": 8409800,
      "changedDate": "2019-02-26T23:13:27.577Z",
      "changeType": "Deploy",
      "changeDetails": "Triggered deployment on 'Single ScaleUnit'"
    },
    {
      "releaseId": 8409800,
      "changedDate": "2019-02-26T23:48:06.163Z",
      "changeType": "Approve",
      "changeDetails": "Approved pre-deployment approval on 'Single ScaleUnit'",
      "comment": ""
    },
    {
      "releaseId": 8409800,
      "changedDate": "2019-02-26T23:55:55.393Z",
      "changeType": "Deploy",
      "changeDetails": "Succeeded deployment on 'Single ScaleUnit'"
    },
    {
      "releaseId": 8409800,
      "definitionSnapshotRevision": 1,
      "changedDate": "2019-02-26T23:11:21.67Z",
      "changeType": "Create",
      "changeDetails": "Created 'Draft-8510'"
    },
    {
      "releaseId": 8409800,
      "definitionSnapshotRevision": 2,
      "changedDate": "2019-02-26T23:11:50.72Z",
      "changeType": "Update",
      "changeDetails": "Updated 'Draft-8510'"
    },
    {
      "releaseId": 8409800,
      "definitionSnapshotRevision": 3,
      "changedDate": "2019-02-26T23:13:22.72Z",
      "changeType": "Update",
      "changeDetails": "Updated 'Draft-8510'"
    }
  ]
}

Enjoy !!

Manage release permissions

Aseem Bansal [MSFT] — Mon, 07 Jan 2019 10:30:13 GMT

Last week one of the customer reported that they are not able to manage the folder permissions of release definitions because they denied permissions to manage permissions and due to which the UI to manage security is not showing up even for project collection administrators. We fixed the UI bug in our latest code so that it always show up the security dialogue and Nishu Bansal wrote a powershell script which uses the security rest APIs to manage the security. I am pasting the script for you so that you can learn how to programmatically manage RM security.

$accountName = "" $projectName = "myproject" $personalAccessToken = "" $user = "aseemb" $base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $user,$personalAccessToken)))

function getProjectId() { $projects=((Invoke-RestMethod -Method Get -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)} -ContentType "application/json" -Uri https://$accountName.visualstudio.com/_apis/projects?api-version=4.1).value | Select-Object id, name) $projects | % { if ($_.name -ieq $projectName) { return $_.id } } }

function getACEObject([string] $descriptor,[int] $allow, [int] $deny) { $aceObject = New-Object PSObject $aceObject | Add-Member -type NoteProperty -name descriptor -Value $descriptor $aceObject | Add-Member -type NoteProperty -name allow -Value $allow $aceObject | Add-Member -type NoteProperty -name deny -Value $deny return $aceObject }

function Set-ACE([string] $folderPath) { $projectId=getProjectId $token=("{0}/{1}" -f $projectId, $folderPath) $result=((Invoke-RestMethod -Method Get -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)} -ContentType "application/json" -Uri "https://$accountName.vsrm.visualstudio.com/_apis/AccessControlLists/c788c23e-1b46-4162-8f5e-d7585343b5de?token=$token&api-version=4.1&includeExtendedInfo=true").value) $ace=($result | Select-Object acesDictionary).acesDictionary Write-Output ("Existing ACLs") foreach($info in $ace.PSObject.Properties) { $aceObject = getACEObject -descriptor $info.Value.descriptor -allow $info.Value.allow -deny $info.Value.deny Write-Output ($aceObject) } $aces = @() foreach($info in $ace.PSObject.Properties) { $descriptor=$info.Value.descriptor # if ($descriptor -match '-0-0-0-0-1') { #$allowValue = $info.Value.allow -bor 512 # Enabling Allow bit for Release Administer permissions $allowValue = $info.Value.allow $denyValue = ($info.Value.deny -band (-bnot (1 -shl 9))) # Disabling Deny bit for Release Administer permissions $aceObject = getACEObject -descriptor $descriptor -allow $allowValue -deny $denyValue Write-Output ("Setting new ACE") Write-Output ($aceObject) $aces += $aceObject # } } if ($aces.count -gt 0 ) { Write-Output ("Setting new ACLs") Write-Output ($token) $aclObject = New-Object PSObject $aclObject | Add-Member -type NoteProperty -name accessControlEntries -Value $aces $aclObject | Add-Member -type NoteProperty -name merge -Value false $aclObject | Add-Member -type NoteProperty -name token -Value $token $request = $aclObject | ConvertTo-Json $result=((Invoke-RestMethod -Method POST -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)} -ContentType "application/json" -Uri "https://dev.azure.com/$accountname/_apis/accesscontrolentries/c788c23e-1b46-4162-8f5e-d7585343b5de?api-version=5.0-preview.1" -Body $request).value) Write-Output ("Output") Write-Output ($result | ConvertTo-Json) } }

Set-ACE -folderPath "/"

Enjoy !!

Release pipeline review of an internal team

Aseem Bansal [MSFT] — Tue, 11 Dec 2018 09:37:34 GMT

Couple of months back, one of my colleague in IDC mentioned that his team faces frequent issues in their release pipeline & asked about known issues. Since there were no known issues, we scheduled a review where his team talked about the issues that they were facing and Divyansh from my team & me gave recommendations on how to come out of it. In this post, I am pasting the list of issues with their recommendations so that you can also benefit from it.

Issue	Recommendation
At times Azure Devops build agents fail to initialize and it happens primarily because of unavailability of disk space on agent.	Enable maintenance jobs to cleanup the agents periodically.
In release pipeline, we use manual steps for process reasons. These steps take lot of time during deployment.	Use manual intervention task in agentless phase in release pipeline
If during deployment a step fails for whatever reason, we need to start all over again starting from build generation.	Fix the release name pattern so that release names can be different for same builds.
Many times especially during weekends DFS store is not available for build	The internal team was using on-prem storage to store the Build output, and this had lower availability, especially over the weekend, thus making the build system less reliable. The recommendation was to use cloud storage to store their build, and expose that as an custom artifact for RM.
Enlistment initialization takes lots of time(>30mins)	The internal team decided to split the gigantic build package into smaller ones, only one of which was required by them.
Package management	The internal team abandoned their homegrown packaging system in favor of Azure Devops Package Management, which was far more reliable.
Internal build is not so quick or reliable	The internal team decided to abandon their homegrown build system in favor of Azure Devops Build pipelines.

Enjoy !!

New releases hub - Common questions

Aseem Bansal [MSFT] — Tue, 11 Dec 2018 08:57:38 GMT

We recently made the new releases hub the default hub on Azure Devops and here are the common questions that customers have asked. 1. Where can I find deleted releases hub? 2. Where is the overview tab ? It is replaced with "Currently deployed" option on the releases page. 3. Earlier I used to see all releases that happened yesterday by clicking on "All Release Pipelines". What should I do now? We dont have this feature but we have started working on it and it should be available on Azure Devops in next couple of months. 4. Earlier I used to view the overview of all definitions by clicking on "All Release Pipelines". What should I do now? We dont have this feature but have added it to our backlog and should be able to get to it soon. In case you have any feedback which is not captured above, please feel free to leave comments.

Liveness in Release Management UI

Aseem Bansal [MSFT] — Thu, 27 Sep 2018 14:37:19 GMT

Over last few weeks, we had some Azure Devops (formerly VSTS) customers who reported that the liveness in release management UI does not always work well. They mentioned that there are few times when the UI show stale status and they have to manually refresh to view the latest status. In this post, I want to share a simple way of how you can get away with this problem. We have recently made Azure Devops accounts accessible via following URL (more details here). https://dev.azure.com/{your organization}/{your project}. If you use this URL to access your releases, then the live updates will always work well for you. Enjoy !!

Are you not receiving release notifications for a group?

Aseem Bansal [MSFT] — Mon, 16 Jul 2018 10:48:18 GMT

Today a customer reported that VSTS is not sending approval pending email if the approver is a VSTS group. Customer also mentioned that the approval email is sent if the approver is an individual user. I was able to reproduce the problem on my test account and here are the steps that I did to come out of it. 1. Saw the account level notification admin settings and observed that the default delivery option for all groups is set to "Do not deliver". 2. Saw the notification admin settings for my test group and observed that the default delivery option is set to "Do not deliver". 3. Changed the default setting for my test group to "Deliver to individual member" and it worked. Enjoy !!

Work items between 2 releases

Aseem Bansal [MSFT] — Wed, 11 Jul 2018 07:22:54 GMT

In Release Management UI, we show a nice list of work items that are getting deployed as part of a deployment on an environment. In this post, I will talk about how you can get the equivalent list of work items programmatically. Let us take an example where I have a release (with name RM_M136.9 ) that I want to deploy on my environment (with name R2_WEU1). For this release, here are the work items that you see in the UI. Before we try to find out the same list using RM APIs, let us get the releaseId for release RM_M136.9 and environmentId for environment R2_WEU1. - To get the release id, open the release and take the releaseId from the URL https://mseng.visualstudio.com/VSOnline/_releaseProgress?releaseId=4630482&_a=release-pipeline-progress”. - To get the environment id, open the release definition, click on the environment and take the environmentId from the URL. https://mseng.visualstudio.com/VSOnline/_releaseDefinition?definitionId=17&_a=definition-tasks&environmentId=2461. Now that we have both these Ids, let us use RM APIs to get the same work item list. 1. First of all, get the last deployed release on an environment. To do that, you can do that using this rest API and the response will contain the last deployed releaseId.

 https://myaccountName.vsrm.visualstudio.com/myProjectName/_apis/Release/deployments?definitionId=mydefinitionId&definitionEnvironmentId=myDefinitionEnvironmentId&deploymentStatus=30&operationStatus=7960&$top=1

Example: - The response had releaseId 4580686 when following call was made.

   https://mseng.vsrm.visualstudio.com/VSOnline/_apis/Release/deployments?definitionId=17&definitionEnvironmentId=532&deploymentStatus=30&operationStatus=7960&$top=1

2. Now get the work items between the release that you are about to deploy and the above found base release. To do that, use the following rest API which will return you the list of work items.


   https://myaccountName.vsrm.visualstudio.com/myProjectName/_apis/Release/releases/myReleaseId/workitems?baseReleaseId=myBaseReleaseId&$top=250

Example: - The response had following workItem Ids when this call was made.


 Request:  
      https://mseng.vsrm.visualstudio.com/VSOnline/_apis/Release/releases/4630482/workitems?baseReleaseId=4580686&$top=250
 Response:
 {
  "count": 47,
  "value": [
    {
      "id": "1298228",
      "url": "https://mseng.visualstudio.com/_apis/wit/workItems/1298228"
    },
    {
      "id": "1292030",
      "url": "https://mseng.visualstudio.com/_apis/wit/workItems/1292030"
    },

   ….
  ]
}

Please try this out and do let us know in case it does not work for you. Enjoy !!

How to create a new kubernetes service endpoint for AKS?

Aseem Bansal [MSFT] — Tue, 03 Jul 2018 09:04:03 GMT

In this post, I will talk about the steps that you should perform to create the kubernetes endpoint for an existing AKS cluster. 1. Go to the endpoints UI -> New Service endpoint -> Kubernetes. 2. This dialog should open where you need to fill the cluster URL, KubeConfig file etc. 3. Since the cluster is in AKS, you can use the azure CLI to get the KubeConfig file and since KubeConfig file contains the URL to cluster as well, we will also get that. 4. Use get-credentials command in az cli to get the KubeConfig file. The exact syntax is as follows: - az aks get-credentials --resource-group --name The above command will output the path to KubeConfig file as shown below. 3. Open the KubeConfig file from this path and get the cluster URL. 4. Copy paste the complete content of the KubeConfig file in the KubeConfig file parameter in the endpoint UI. 5. Enable "Accept Untrusted Certificates", verify connection and press OK. The dialog should look similar to this. Enjoy !!

Ability to sign the service bus message in task

Aseem Bansal [MSFT] — Wed, 27 Jun 2018 13:57:39 GMT

Recently we (Rohit Batra) added capability to sign the service bus message in "Publish to azure service bus" task. In this post, we will walk-through how you can use it in your release/build workflows. 1. Get the pfx certificate that you want to use for signing. In case you want to try out, you can create a self-signed certificate using this code.


# create a new certificate
New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname mydomain.fqdn -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider"

# export the above as a pfx file
$pwd = ConvertTo-SecureString -String "mypassword" -Force -AsPlainText
Export-PfxCertificate -cert cert:\localMachine\my\ -FilePath c:\temp\mycert.pfx -Password $pwd

2. If you want to use azure key-vault to manage this, you can import the certificate to key-vault as shown below and then link the key-vault backed variable group to your definition environment as mentioned here. 3. But if you dont want to use key-vault, then convert the above pfx certificate to a string using this code.


$pfxcert = New-Object System.Security.Cryptography.X509certificates.X509certificate2("C:\temp\mycert.pfx", "mypassword", [System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable);
$certBytes = $pfxcert.Export([System.Security.Cryptography.X509certificates.X509ContentType]::Pkcs12);
$certString = [Convert]::ToBase64String($certBytes);
Write-Output $certString

4. Define a new secret variable with value as the above string in your definition environment. 5. Use the above secret variable in the signing properties. 6. Run a release and you will see the payload is signed. Enjoy !!

Approve a deployment for a pre-configured time

Aseem Bansal [MSFT] — Mon, 22 Jan 2018 05:05:40 GMT

Recently one of the customer asked whether release management offers a way by which they can approve a deployment for a pre-configured time. This means that customer should be able to approve the deployment now but should be able to specify the time at which deployment should start. We have a feature called "deferred approval" for exactly the same problem and a lot of customers (including me in our dogfooding) use that pretty often. This feature enables you to specify the time (along with the time-zone) at which the deployment should start while you are approving a deployment. See the below image for more details. Enjoy !!