I am trying to add a step to execute a powershell script to the release management release template to send customized email on each release. I want to pass in the username of the user who triggered the release, are there any inbuilt variables that manage the username of the user who triggered the release and can be accessed when the workflow is being executed?
All system variables that are provided by MS Release Management can be found here, and the user triggering the release doesn't appear to be part of them, I'm afraid.
Related
Can i run a single job to trigger multiple release pipelines in Azure Devops. We have multiple microservices which are being built and deployed separately that are independent of each other but the business ask now is to treat them as a release and deploy so wondering how that can be achieved off a release tag(1.x.x)which gets tagged for every release run.
We do the same thing for the app I work on. We wrote a PowerShell script to kick off the releases utilizing the DevOps Rest API. The documentation is here: https://learn.microsoft.com/en-us/rest/api/azure/devops/release/definitions?view=azure-devops-rest-6.0.
You basically pass in a list of Release DefinitionIds and then set the status of the latest Release to "inProgress" to start it.
If you want to target a specific release, you can use the searchText query parameter to find a release by the name. We created a variable group with the names of the releases in it and use that to target them.
As a part of Azure pre-deployment condition I need to include a pause which should prompt for user input variable which can be used inside the task.
I need to update the variable in the Azure release task dynamically during run time. For that Is there a way to implement user prompt so that the variable will be overided.
I am afraid this is impossible to update the variable in the Azure release task dynamically during run time.
First, Azure devops does not support prompt for user input.
Second, when we queue a build/release pipeline, all the related data like variables, settings are loaded into the compiler, even if we modify the variable, the modified variable will not be reloaded into the compiler. We have to restart the compiler to recompile the modified variables.
So, it is impossible to update the variable in the Azure release task dynamically during run time.
To resolve this issue, we have to find other workarounds to solve this issue. For example, Usig Settable at release time:
In this case, we could update the variable when you queue the release pipeline.
Or we could use the Logging Command during the release pipeline to update the variable.
If above not resolve your question, please share the reason and situation why you want to update the variable in the Azure release task dynamically during run time, we can try other solutions.
I need to create a script that sets security to a given environment in a given release definition (as input I have TFS url, project ID, release ID and environment ID).
With the script, I need to set all the environment specific permissions:
Administer release permissions
Delete release environment
Edit release environment
Manage deployments
Manage release approvers
I did not find any method for this in the API.
I also tried to sniff the network traffic as suggested in this question. But for this task it looks too difficult. The request body is full of some identifiers (I do not know where how to get them).
The question is: how can I set environment specific permissions via script?
(preferably with PowerShell Invoke-RestMethod)
I think the only way at the moment is to use tfssecurity.exe!
Here is a good guide and also a download of an Excel that helps you to create your tfssecurity statements. You can find tfssecurity.exe in your TFS-Folder.
Link to guide: https://roadtoalm.com/2014/07/28/add-permissions-with-tfssecuritythe-ultimate-reference/
I'm developing Release pipeline for deploying artefacts using TFS 2017 Update3 Release Management. There are various tasks like "Windows Machine File Copy" and "Run Power Shell on Target machines" which needs admin credentials to be passed as input parameters. These admin credentials have Administrative access on target nodes. I'm using Windows service accounts for these. We have an organisational security policy to rotate passwords every month.
With that in mind, it is hectic to update hundreds of TFS release definitions for new password every month.
Do you have a better idea to handle this? Please give detailed answers.
Thanks in advance.
You could use a variable group to store values that you want to make available across multiple build and release definitions. Variable groups are defined and managed in the Library tab of the Build & Release hub. In this way, you can just edit the variable group:
https://learn.microsoft.com/en-us/vsts/pipelines/library/variable-groups?view=vsts
If you want to automate the process you use the solution defined here. This details how to use the TFS API to poke the definitions.
Alternatively you could create your own PowerShell task that sources the password from some alternative source like Azure Key vault or even hard code it into the json task definition itself (don't do this).
You can vote to improve this story here.
I wrote a custom version of the PowerShell task that uses the identity of the agent as part of the WinRM session which greatly simplifies our release definition process.
I'm using Visual Studio Team Services (VSTS), previously known as Visual Studio Online (VSO) to build a Continuous Delivery pipeline. My goal is to follow as close as possible the Continuous Delivery book from Jez Humble and David Farley.
I would like that when a stage (named Environment in VSTS) fails, a notification (an email) is sent to every developers involved in this release. This notification would say either :
You broke the stage (Regression)
The stage was already broken (Failed)
You fixed the stage. (Fixed)
Currently, only the person who created the release manually (or by pushing the commit which triggered the build and after that the release) will receive this email and without the information I want.
I've played a little bit with VSTS API, and can get the associated commits (and the developers email) for a given build (but not for a given release) :
$token = "vsts token"
$endpoint = "https://acme.visualstudio.com/DefaultCollection/MyProject/_apis/build/builds/42/changes?api-version=2.0"
$b64creds = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("$($token):a"))
$changes = Invoke-RestMethod -Headers #{Authorization="Basic $b64creds"} $endpoint
$changes.value | ForEach-Object { $_.author.uniqueName }
I've seen that in VSTS interface, you can see which commits were added between 2 releases. It's very close of what I want even if I didn't found this information in the API. But even with this information, a same release definition is used for all branches of my project, so for example Release-26 will be a feature branch and Release-27 will be develop. It doesn't make sense to compare these 2 releases.
I know that I can get the build ID in a release stage from the environment variable, and after that use my script above and create a PowerShell Task or a Webservice plugged on VSTS. But it will only work if a release is triggered for each build, which is not always the case.
Do you know a (better) way to send this notifications with VSTS ?
And do I use the right tool for that sort of things ?
You can only send the email alert to "Environment owner" & "Release creator" and there isn't any way to customize the content in the email alert for now, you can submit a feature request on VSTS User Voice.
Rest API is a good tool to get these information. But you mentioned that you are using the same release definition for all branches. This does not make sense. Different branches refer to different version of your project, why do you deploy all of them in one release pipeline? If you configure your workflow to one release definition per branch, the resolution would be more easy. You just need to get the Build ID for previous release, and then get the changes after that build. And you can also add a powershell task to create a lable/tag for TFVC/Git repositories for current release version so that you can get the changes between the labels/tags.