I have recently moved from Classic release to YAML release pipeline. With Classic release I would simply trigger manually the deployment I was interested in (Dev, Integration, UAT or Production).
However with YAML pipeline I use stages and they are triggered automatically after building. To prevent that, I've added Approval guard on the Integration stage as shown below.
However the pipeline was running indefinitely and would never end. So I've set a 5 minute timeout on approval and now the Integration stage is marked as Skipped if nobody approves.
I feel I'm not doing it the right way as it is quite different from classic release.
Is this the correct way to handle release pipeline when using YAML ?
Is this the correct way to handle release pipeline when using YAML ?
Yes, you are on the correct way (At least for now).
Just as you said in the question, Azure devops does not support manually triggered stage(s) in YAML multi-stage pipelines. So, we could not simply trigger manually the deployment stage we are interested in.
There is an On Roadmap user voice about this request:
Manually triggered stage(s) in YAML multi-stage pipelines
You can look forward to it, and I believe it will meet us soon.
So, your workaround is correct for now.
I would like to have a manual stage in a build pipeline that triggers a release pipeline and passes build number. Is it possible to accomplish this without having to add extensions from marketplace? I am pretty new to Azure, our organization just switched from Bamboo, so I am still getting acquainted with Azure DevOps Thanks!
We can’t directly call the variable of the build pipeline in the release pipeline, as a workaround, we can store the variable to artifact->publish artifact->download this artifact in the release pipeline, then we can use the build variable in the release pipeline.
I am using azure build and release pipelines. I understand that build pipeline produces an artifact that can be used by release pipelines and deployment can be organized into stages with options to deploy/re-deploy stage.
However, I also notice that all tasks available in release pipeline are also available in the build pipeline. Also the documentation for build pipeline states that it can be used to build, test and deploy. So what exactly is the benefit of using release pipelines?
The pipelines under "Pipelines -> Releases", are classic deployment pipelines made with the GUI.
The new YAML pipelines are always under "Pipelines -> Pipelines" and allow both build and deployment jobs: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops.
By using deployment jobs instead of classic Releases, the deployments will show up under "Pipelines -> Environments".
So in this way it makes sense the same tasks are available on both sides since both allow defining deployment workflows.
YAML pipelines do not have the same capabilities as classic Releases yet though, I think release gates was still missing.
For classic UI-format build and release pipeline:
Usually we use Build Pipeline to build/test our project and output the tested software binaries.
Then we can use Release Pipeline to deploy the artifacts from Build Pipeline to more than one stages depending on we need. So that, we only need to run the Build Pipeline once to get the artifacts(containing the software binaries) and we can use Release Pipeline to reuse and deploy the artifacts to different environment. (Develop, Product...)
Of course we can use Build Pipeline to run some deploy tasks, and we can use Release Pipeline to run the build and test tasks. We can but we shouldn't(not recommended), configuring the Build and Release UI pipeline can make the workflow of how we build/test(more related to CI)=>deploy(more related to CD) better.
And if you're using Multi-stage pipeline, you don't need to use the Release(UI) Pipelines. You can define CI/CD steps in one xx.yml file.
It is the same tasks but not the same processes.
Nowadays, I would say Pipelines are responsible for Continuous Integration, and Release Pipelines are more about Continuous Delivery. When all deployment features will arrive to YAML pipelines it will not be the case.
As you said, Azure Release Pipelines can use and automatically trigger on result of YAML or classic pipelines and you can use different agents. Agent for YAML or classic pipelines need all tools to compile, test and assembly the code when Agent for Release, need the tools for deployment and correct access rights to target environment.
In Release pipelines you can organize your deployments by environments/stages more easily, add steps which could be launched separately with out need to relaunch the whole pipeline (like application recovery or switch to production).
The workflow of Release Pipelines is more visual than in YAML or Classic Build pipelines.
From my experience the main difference is in Approvals and Gates features, for now.
You can try to implement the whole CI/CD process just on YAML pipelines but it could be much easier to use both Azure Pipelines capabilities to separate the logic of CI and CD, at the moment, as deployment features of YAML pipelines are still in development.
in principle there isn't. its just that usually release pipelines are geared towards deploying stuff and build pipelines towards building stuff. jenkins, for example, only had builds. and you'd be releasing with builds. it really depends on the solution you are using. octopus cannot really build stuff, but can release stuff and got tools to make releasing easier.
in ADO you can have stages in release pipelines, so you can do promotes easily, you have approval gates, etc
I have been looking for implementing deployment approval within bitbucket pipeline. Basically it's similar to Octopus deploy you can implement 'awaiting for approval' step. Has anyone ever implemented it with bitbucket pipeline ?
Yes, you can trigger steps manually by specifying trigger: manual in your step.
See the docs for more information
The azure pipeline build task for github tends to build all the commits in a PR sent. I would like it to build only the last commit. That is I would like the other build jobs started for the previous commits in a PR (except for the last one) to be cancelled automatically without manual intervention. This is to reduce the number of build jobs queued at the same time for a given PR.
How do I achieve this in Azure Pipelines for CI/CD. I can do it in travis easily and would like to find out if it is available in Azure Pipelines for CI/CD and if so how to achieve it.?
I believe this behavior to cancel existing queued pipelines on PR update became the default behavior for Azure-DevOps with the Nov-12-2018 release with this feature. It doesn't look like it is flagged for 2019 On-Premise, so I'd expect this won't be available On-Premise for a while.