We have 20 release definitions that need to be deployed together for a deployment to an environment.
Is there a way to link the release definitions and manually trigger a "global" release to deploy all 20 release definitions to a specific environment?
At this moment we manually start each release, lots of clicking!
Thank you!!
You could create/manage releases through the VSTS API.
https://www.visualstudio.com/en-us/docs/integrate/api/rm/releases
specifically look at the example for "Start deployment on an environment".
An example scenario could look like this
Create a release from the API
POST https://{instance}/{project}/_apis/release/releases?api-version={4.0-preview.4}
The response "A Release object" will contain key elements you need to trigger environment deployments. You'll need the Release ID and the environment ID(s).
Find this in the response release ID will be returned in the response, save it, this is your key to automating environment deployments later
Let's say the release ID created was 77 and the environment (Production) id was 3
The final step is to kick off a release:
PATCH https://{instance}/{project}/_apis/Release/releases/77/environments/3
{
"status": "inProgress",
"scheduledDeploymentTime": null,
"comment": null
}
There is no such settings to trigger multiple release definitions.
For now a release environment can be triggered with three types: After release, After environment, Manual only.
If you manually deploy, you should create releases of the different release definitions separately.
The workaround is add all the tasks from different release definitions into one release definition (merge multiple release definitions into one release definition), and then create a release for the release definition.
You can have a build definition and link that build definition to all of your releases with Continuous Deployment trigger turned on.
Whenever a build is completed, the release on all the 20 RDs will be triggered.
Now this build could actually produce some meaningful artifact or it can act as a trigger point for all the release definitions.
Related
I am trying to delete a Release from a Legacy release Pipeline but when selecting the Delete option I get the following error...
VS402946: 'My-Release-2022-01-06' cannot be deleted as it is currently deployed on stage(s) Staging.
This is nonsense in "real world" as this Release pipeline has since been replaced with another pipeline so this isn't deployed anywhere anymore.
This was a badly generated release - I don't want to remove the pipeline for legacy tracking reasons. Can this be done?
Three steps when you have an older release def you need to delete and it was previously deployed.
Edit the definition, and delete all the environments.
create an environment with a default name that is different than the original and save.
Delete the environment as it will not see it as a valid deployment.
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.
We're using on-prem AzureDevopsServer2019, with on-prem build agents. I'm trying to create a new release, which consists of 3 artifacts.
The (retained) build artifact I want doesn't show in the available builds comboboxes of the new release (this has happened on more than one artifact)
Alternatively, when I try and create a release directly from the retained build, I scroll through my many historic builds, find the "missing" build, click release, populate the other artifacts in the new release, then when I click "Create" get:
"VS402962: No artifact version ID is specified corresponding to
artifact source 'MyBuild'. Specify a valid value and try again
Any idea what's up?
Build artifact missing from new release's combo, creating release directly from retained build causes VS402962
You should check if you specify the projectname for the alias, it should be the source alias. Since you want to use the build artifacts, the “alias” variable should be your build definition name not your project name.
If above not work for you, try to create a new build pipeline, there is a ticket report this issue, but there is no one effective solution. This is an annoying issue in Azure DevOps:
Unable to release ~20% of the pipeline builds to any release pipeline
If you encounter this too, please reopen it and add your feedback and more useful information.
I'm trying to configure Azure DevOps Release pipelines for our projects, and I have a pretty clear picture of what I want to achieve, but I'm only getting almost all the way there.
Here's what I'd like:
The build pipeline for each respective project outputs, as artifacts, all the things needed to deploy that version into any environment.
The release pipeline automatically deploys to the first environment ("dev" in our case) on each successful build, including PR builds.
For each successive environment, the release must have been deployed successfully to all previous environments. In other words, in order to deploy to the second environment ("st") it must have been deployed to the first one ("dev"), and in order to deploy to the third ("at") it must have been successfully deployed to all previous (both "dev" and "st"), etc.
All environments can have specific requirements on from what branches deployable artifacts must have been built; e.g. only artifacts built from master can be deployed to "at" and "prod".
Each successive deploy to any environment after the first one is triggered manually, by someone on a list of approvers. The list of approvers differs between environments.
The only way I've found to sort-of get all of the above working at the same time, is to automatically trigger the next environment after a successful deployment, and add a pre-deployment gate with a manual approval step. This works, except the manual approval doesn't trigger the deployment per se, but rather let an already triggered deployment start executing. This means that any release that's not approved for lifting into the next environment, is left hanging until manually dismissed.
I can avoid that by having a manual trigger instead of automatic, but then I can't enforce the flow from one environment to the next (it's e.g. possible to deploy to "prod" without waiting for successful deployments to the previous stages).
Is there any way to configure Azure DevOps Release Pipelines to do all of the things I've outlined above at once?
I think you are correct, you can only achieve that by setting automatic releases after successful release with approval gates. I dont see any other options with currect Azure DevOps capabilities.
Manual with approval gates doesnt check previous environments were successfully deployed to, unfortunately.
I hope this provides some clarity after the fact. Have you looked at YAML Pipelines In this you can specify the conditions on each stage
The stages can then have approvals on them as well.
We currently have a setup where we schedule a pipeline to create a new release definition at 4am every Sunday.
We have setup one of our test stages to trigger deployment 'After Release'.
This works perfectly and deploys the new release automatically, however the issue we have is that because we have set the 'After Release' trigger on our test stage, every time someone creates a release definition manually then the stage deployed as well.
We only want the stage to deploy if the release definition was created automatically not manually.
Our issue seems to stem from having to set the 'After Release' trigger on the stage.
Is there a way to configure this not to deploy on manual creation? or another approach we could take?
Depending on the version you are using, there should be an option when creating the release to change the stage trigger from automatic to manual. You could just provide training for those with release creation rights to make sure they specify that setting.