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.
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.
I have a solution where I want to implement the whole CI/CD circuit, Its a simple Web API in dotnet core 3.1
When it finished, my pipeline build triggers the release deployment, but somehow it stays idle until I manually select "deploy", and I want that step to do it on automatic, if the build passes the checks on the pipeline then, it should trigger an automatic release to my environment.
Nevermind guys, I'm dumb the release trigger needs to be set here:
and I didnt do it.
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 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.
We are using octopus to deploy our project. A bunch of steps which gets executed during the deployment. One of them is a powershell script and that powershell script is a work in progress.
However to test the script we have to perform a dummy check in or can create a new release in octopus after we change the build powershell script step, and it will pick up the build steps straight away and does not cache, else the script which gets executed is the previous version.
I do not know if this is caching or some other issue. I think this is some kind of issue with octopus or setting which I am missing.
Please help.
An important aspect of deployment automation is ensuring that deployments are repeated exactly each time they run.
When you create a release in Octopus Deploy, the artefacts, process, and variables are all "locked in" for that release. This means no matter what changes you make, for the lifetime of that release it will be performed identically every time.
If your deployment tool didn't do this, the same relase could work in your test environment, but then fail in the live environment because the deployment process changed in some way.
In effect, you release changes to the deployment process in the same way you release changes to the application itself.
This is why you need to create a new release in Octopus Deploy in order to see the changes you make.
This is both a blessing and a curse... On the one hand - your existing release scheduled for Production is protected from changes being made in lower environments. On the other hand - you are forced to recreate a release if you need to make a slight process change mid-cycle. This is arguable the correct approach since you would want to test any changes - but maybe not relevant if your changes can only be tested in higher environments (e.g maybe only Production is load balanced).
The software does allow to update Variables mid-cycle, but not Process Steps. I believe this feature is been requested for a future release.
http://help.octopusdeploy.com/discussions/questions/5130-how-to-update-a-single-variable-in-an-existing-release