I have an Azure DevOps release pipeline setup to release to my test environment at a scheduled time in the morning at 4am. The deployment queue setting is set to "Deploy latest and cancel the others".
We manually released #931 to test on 4/27 at 1pm. Release #929 never was never (manually) released to test on 4/27. On 4/28, release #929 was released to test at 4am (scheduled).
I don't want this behavior. I assumed that since #931 was released to test, #929 would be "cancelled" and not released to test. Is there a setting or modification to make this the actual behavior?
Below are some screenshots if they help:
"Deploy latest and cancel the others" only applies to releases that are currently pending, not scheduled ones. The cancel is referring to the release itself, not the schedule.
Per the documentation:
Use this option if you are producing releases faster than builds, and you only want to deploy the latest build.
I've searched for simple ways to conditionally fire the schedule, but I wasn't able to find one. The way I work around it is have the schedule always create releases but have the tasks configured to only execute under certain conditions.
Related
Currently i'm using Azure DevOps Rest API call from the CI to invoke the releases from a release definition. During the process i'm invoking releases one after another. All releases starts at the same time. Currently i have added a manual intervention at the start of every releases. SO when first release got finish i will go and resume the second releases and on completing that resume the third releases. But i want to remove this manual intervention and releases should start only after finishing the previous releases. For example if i'm triggering three releases
Release1,
Release2,
Release3
While Release1 is running both Release2 and Release3 should wait. On completing Release1, the Release2 should start without manual intervention and Release3 should still wait. On completing Release2, start Release3 without manual intervention.
While Release1 is running both Release2 and Release3 should wait. On
completing Release1, the Release2 should start without manual
intervention and Release3 should still wait. On completing Release2,
start Release3 without manual intervention.
This will only occur when you are trying to create 3 releases in the same agent. If there have different agents, there should be running in parallel.
Since you are using a single release pipeline. Not sure why you want the later release executed after all of stages of previous release completed.
In release, the stages are independent of each other.
You could also take a look at this similar question. How to configure an Azure DevOps release to complete all its stages before starting a new one
As I specified, I used Azure Devops Rest API to invoke multiple dependency releases. But I was calling all the releases one after another from the CI process itself. So I put the Manual intervention for the following releases. But now I updated my process to call the dependency release just after finishing the parent release. So I again took advantage of the REST API feature for the same. Also, the variable collection is same for all the releases. So I'm setting the release variable through REST API and use the same variable for setting the variable for successive release. So Release2 is called after calling Release1 and Release3 is called after calling Release2 using REST API.
In Azure DevOps I have a release pipeline that uses the auto-redeploy trigger to deploy the last successful release if the current one fails.
I have a script that I want to run only when a release has been requested by the auto-redeploy trigger.
Is there any way to detect that a release has been triggered in this way?
Is it possible to detect that a release has been triggered by the
auto-redeploy trigger
For this issue , first we can view the Deployments in Release pipeline to check if the deployment is triggered as expected.
From the figures, we can see that if the current stage deployment fails, auto-redeploy trigger redeploys the previous successful release, and the current release stage still displays the failed state. So if you set an auto-redeploy trigger and your current stage is in a failed state, then the previous release should trigger redeployment.
The previous successful release is triggered instead of the current release, so it can only be detected in Deployments. If you want to detect if the current release is triggered by the auto-redeploy trigger, I am afraid this is currently impossible.
In addition , you could add your request for this feature on our UserVoice site, which is our main forum for product suggestions. You can comment and vote it there. The product team would provide the updates if they view it.
I have a pipeline that is automatically building and deploying code to my staging environment. For my production environment I have a pre-deployment manual approval gate so that only releases that have gone through some review will go out to customers. So far so good.
The problem is that as new releases go out to the staging environment there is a growing list of releases that are now queued for this manual approval. In order to release the most recent version I need to go and manually reject each of the intermediate releases. This has become a laborious process.
I would like to automatically reject the production deploy of the previous release every time a new release goes to staging.
I've looked at the MS docs, SO, the pipeline settings, the available pipeline release tasks and can't find a way to do this.
Release History showing old release queued for approval:
Looks like this behavior can be controlled by making a change in the Deployment Queue Settings area. Switching to "Deploy latest and cancel the others" will automatically cancel the previously queued release and queue the newer one. If you have Slack integration turned on (as I do) you will see a cancellation message.
So long as your process is simple enough that you know when new builds are being made, this feels like good behavior. It gives you a basic manual gate without adding any other overhead.
There is more documentation here: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/stages?view=azure-devops&tabs=classic#queuing-policies
Deployment Queue Setting: subsequent releases
We have a release pipeline that automatically creates a new release every time a build is completed.
At that point, we have a release candidate, so this makes sense. Every build is potentially releasable.
In the pipeline, the Release goes automatically to dev. So we get a check in and the build and then it goes to the Dev server.
There is an approval gate on the release moving to Stage. The approval usually takes a while and development will continue while waiting for the approval.
Now, we have 10 - 15 builds that are listed as queued.
So, I need to automatically cancel each one in order to start the release of the LATEST build to stage.
Is there a way to automatically cancels a release when a newer version makes it into the queue or should I instead create a POST-approval in the Dev stage that keeps it out of stage until someone hits "go" on that release version?
Am I using this right?
Change your deployment queue settings so that only the latest build is eligible for deployment to that environment.
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.