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.
Related
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.
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 an Azure DevOps CI Build and Release pipeline in following setup:
CI Build runs with each new commit in develop branch and creates a Build Drop (Artifact)
Release pipeline runs with each new Artifact and deploys to INT and eventually to PROD (after manual approval)
I would like to add a 3rd stage (called eg. MONITOR) which would run after the PROD release every night using the same drop as the PROD stage used, with following schema:
[Build Drop] -> [INT] -> manual approval: [PROD] -> nightly scheduler: [MONITOR]
This seems to be impossible to me, do you know how to achieve this goal?
Following is crucial for me:
the MONITOR and PROD run always from exactly the same Artifact
MONITOR is executed only if the PROD was successful
if there is a newer PROD release, the old MONITOR is not executed any more and instead the newest one is executed using the newest Artifact which made it to PROD
I tried so far following:
merge develop to master when the commit made it to PROD. And then used scheduled nightly Build from master with MONITOR stage - it works, but MONITOR uses different Artifact than PROD, so not usable for me
used scheduled trigger for MONITOR after PROD - does not work, the MONITOR is executed only once at scheduled time and never again
created extra release pipeline based on specific Artifact version with a scheduled trigger - this works, but I have to maintain the specific Artifact version manually with each successful PROD release. Another caveat is that I have to use 2 separate pipelines which makes the overview not so nice. (but, so far the best solution I achieved)
do you have better ideas? many thanks
What I would do is have 2 separate Release Pipelines.
This allows you to schedule the release without producing a new artifact (scheduled build).
Then, I would do some of what #Soccerjoshj07 suggested in that I would invoke the REST api in a task on the MONITOR pipeline/stage.
I would make the REST api call to the Releases endpoint to get the top=1 releases for releasedefinitionid=x. Then use the Release Environment endpoint to get the PROD environment for that latest release id. With the environment in hand, check the status for succeeded. If not, fail the release.
Edit as per new requirement outlined in comment
Given PROD.1 is succeeded and PROD.2 is failed when MONITOR is triggered, then the artifact from PROD.1 should be used for MONITOR.
With this criteria I would change some things. Rather than have the MONITOR go digging for the latest PROD release and fail if the latest is failed, I would make the successful PROD stage tag its build artifact and employ artifact filters on the Monitor pipeline.
The tagging can occur via the REST api or using the Tag Build or Release Task from Colin's ALM Corner Build & Release Tools and might look like this:
Are you using a YAML template, and if so have you played with the cron schedules? https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#scheduled-triggers
If using classic Release UI, I think you can have the definition trigger be on a schedule but that would queue the entire definition. You might have to get creative with variables and maybe create 'isScheduled=true' and use that to determine if it should skip tasks.
Other ideas:
Create a logic app or function app that calls the REST API? Sample app and github link here: https://oshamrai.wordpress.com/2019/04/22/azure-devops-rest-api-19-queue-builds-and-download-build-results/
The Azure-Devops AZ CLI extension might be easier, though: https://learn.microsoft.com/en-us/cli/azure/ext/azure-devops/pipelines/build?view=azure-cli-latest#ext-azure-devops-az-pipelines-build-queue
Beside setting up two release pipelines, if you want to use scheduled trigger for only one Stage, I am afraid there is no such out of box way to achieve that, scheduled trigger is only for entire pipeline.
As a workaround, you can add a custom condition for the job of MONITOR stage.
For example in yaml:
- stage: MONITOR
jobs:
- job:
condition: and(always(), eq(variables['Release.Reason'], 'Schedule'))
steps:
In UI , you can set this in Run this job of agent job:
In this case, the stage only executed when the release triggered by scheduled trigger. If the release is triggered by other reasons, the MONITOR stage will be skipped .
The limitation of this workaround is that when your pipeline is triggered by a scheduled trigger, two other stages are also executed.
Or write a script with powershell task (in INT/PROD stages) to determine whether Release.Reason is Schedule. If yes , skip the current stage.
For how to obtain the latest artifact version of PROD and determine the deployment status of PROD, you can refer to the two answers above.
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.