I have a problem in Release Management 2013. A release was failing in its deploy actions, so it was stopped, giving it status Cancelled. Then the release was abandoned. However, still two action are still In Progress, after two days now. I have full rights to edit and manage all parts of this release, but now unable to stop, delete or retry this release.
New releases for the same target server give the following error:
New deployment is not allowed as another deployment is in progress.
Retry the deployment after sometime.
Release Management Monitor service was restarted but this didn't help.
Release are based on vNext templates
Anybody idea how to resolve this?
There is an option to force reject a run-away release in Release Management 2015.
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.
Is there any tool can monitor helm release ?
You may come up with this one https://github.com/ContainerSolutions/helm-monitor, but i don't want automatic rollback by plugin. This is intrusive to our ci/cd deployment.
what i need.
1. i can integrate with grafana to see a history of the release and also its status in history
2. I can set up alerts when some release is stuck in pending or failed then i can notify related teams
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.
I found that we can define build life time from “Retention” and it is maximum 30 days. Consider I have a release named “Release1” and it is associated with build artifact from Build 1.0.2016123.1. Now I want to perform release after 40 days from build creation. In this case will Release1 possible from Visual Studio Team Services (was Visual Studio Online)?
If not possible to Release, then how we can manage this type of scenario?
Waiting for your valuable response.
There is a "Retain indefinitely" option you can set for the build as an exception of the retention policy:
Managed completed builds: After a build has completed, you can rate the quality of the build. You can request a new build for any
completed build. You can delete completed builds that are no longer
required.
You can specify that a build should be retained indefinitely, as an
exception of the defined retention policy. For example, you might do
this for released builds.
From Release: