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.
Related
As written deploy pipelines can be pushed manually. I want to know if there is a way to stop the deploy from happening unless all pervious stages are done.
For example if I push deploy on Production, the Production deploy should check that Dev, Test, and Pre-Prod completed successfully before continuing.
I looked at deploy gates, but there does not seem to be anything in there for this condition.
I am actually surprised this is not part of the tool design. As written out of the box someone can push a deploy to Prod even if Dev, Test, and Pre-Prod aren't completed at all.
Does Microsoft just want us to rely on approvers to eyeball the situation? I am not sure how to constrain deploys for this particular condition.
You can link the stages together, so that the deployment happens first on dev, and only if that succeeds it will go to pre-prod, and then prod.
However, even with stage dependencies, I think you can still deploy at any stage at any time directly. To have more safeguards, you can add a script to your deployment steps that will check that previous steps are completed using Azure DevOps API.
I'm new-ish to Azure DevOps, so I've missed how it got to where it is. By that I mean that I've seen two different approaches for deployment to environments and I'm not sure which superseded which:
Using a Release Pipeline and Defined Deployment Groups to deploy across stages (environments) See here
Using a Deployment Job in a Pipeline, then using a release pipeline to orchestrate pushing it to different environments - See here
It's interesting that the first link MS docs refer to as being classic, however the latter is not.
I'm currently using Deployment Groups to define the App Servers I deploy to for each environment - then each stage in my Release pipeline targets a different deployment group (environment). This seems the most fluent and natural of the solutions. However, it niggles me that the Environments I setup in the Environments section still maintain that they have never been deployed to - but the deployment groups have recorded the deployments as I expect. Also, the environments allow me to set useful stuff like "business hours" to wake the environment machines.
I looked and tried out some of the approach in the second link I posted - however, this just didn't seem intuative to me - and I can't find much in the DevOps docs to support this approach. I can see the benefits in that you can store your deployment pipeline as code in your repo, and that you have finer controller over the whole process - but I couldn't get variables from the library to be used in any of the replace variables steps or really understand where the release pipelines fit in.
So, I guess I after an inkling of what "best practice" is in this fairly straight forward scenario. I wondering if it's a blend of the two, but to be honest - I'm a bit lost.
Release pipelines and deployment groups have been around for longer than Azure DevOps has been named Azure DevOps. The YAML releases are rather recent. It isn't ever spelled out explicitly, but in my mind it comes down to how you plan on delivering your product.
If you are doing Continuous delivery (choosing when to release, maybe daily, weekly, or quarterly) then I think you must use release pipelines. You might choose this also if you have multiple environments that maybe aren't in the path to production that would want to deploy.
If you are doing Continuous deployment (every push that passes tests goes to production without any real human intervention), then I imagine you'd choose to use the YAML stages. This is kind of spelled out in your second link as the approach for deploying with "release flow", which is Microsoft's approach for delivering changes for Azure DevOps.
I am implementing azure devOps in Azure Data Factory.
My development environment ADF is integrated to a git repository.
I have created a build pipeline for building artifacts when there is a change in adf_publish branch.
My next step is to deploy the ARM template artifact to the PROD environment.
Suppose there are many triggered pipelines in the PROD environment and few pipelines were running in the PROD env at the time when the DEV changes are getting deployed to PROD.
My questions are:
How the changes are deployed from DevOps to PROD environment? Will it delete and replace all the pipelines and triggers from DevOps or It will pick only the changes and update the PROD env without touching the unchanged pipelines?
Suppose a pipeline is running in PROD env at the time of deployment, what will happen to that pipeline run?
Suppose there is a triggered pipeline at 3:00 O clock and deployment starts at 2:55 and ends at 3:05. What will happen to that triggered pipeline which was supposed to run at 3:00?
Any one having a clear idea about above questions or Is there any documentation for reference to obtain answers for these questions?
I have gone through Keeping deployment mode as Incremental instead of keeping it as Complete at the time of ARM template deployment. Will that option do all the tasks which I asked above?
How the changes are deployed from DevOps to PROD environment? Will it delete and replace all the pipelines and triggers from DevOps or It will pick only the changes and update the PROD env without touching the unchanged pipelines?
It depends on the deployment mode you choose.
Deployment Mode: This specifies the deployment mode in which the Azure resources specified in the template have to be deployed.
Incremental mode handles deployments as incremental updates to the
resource group . It leaves unchanged resources that exist in the
resource group but are not specified in the template. Complete mode
deletes resources that are not in your template. Validate mode
enables you to find syntactical problems with the template before
creating actual resources. By default, incremental mode is used.
Suppose a pipeline is running in PROD env at the time of deployment,
what will happen to that pipeline run?
Your deployment will fail, and you may receive a 409 conflict error message. You could check the document Best practices for CI/CD：
Pre- and post-deployment script. Before the Resource Manager
deployment step in CI/CD, you need to complete certain tasks, like
stopping and restarting triggers and performing cleanup. We recommend
that you use PowerShell scripts before and after the deployment task.
For more information, see Update active triggers. The data factory
team has provided a script to use located at the bottom of this page.
Suppose there is a triggered pipeline at 3:00 O clock and deployment
starts at 2:55 and ends at 3:05. What will happen to that triggered
pipeline which was supposed to run at 3:00?
Similar to your second question, the pipeline should not be triggered (or in the pending state), but I still don't have an instance to test such a scenario.
I've been looking into Azure DevOps and I'm puzzled by something: Microsoft seem to be strongly recommending the use of YAML pipelines instead of classic ones; fair enough, but they need to replace all the functionality that was in classic pipelines. How am I meant to replace the "release pipeline" functionality with YAML pipelines?
So for example, with classic release pipelines, I could setup a pipeline to deploy to production that had a manual trigger (see 'Manually by a user'):
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=azure-devops#pull-request-triggers
What's the YAML pipeline equivalent to this? I obviously don't want a trigger that automatically deploys to production - I always want that deployment to be initiated strictly manually - but the help article doesn't seem to provide any YAML alternative.
As Daniel comments above, Yaml pipeline supports multi-stage yaml pipelines for CD. You can check Azure DevOps Pipelines – Multi-Stage Pipelines and YAML for Continuous Delivery for more details.
Azure devops yaml multi-stage pipeline and classic release pipeline can both be used for CD, however they do have some difference. And as I know no feature in YAML pipeline can be equivalent to the manual trigger in Classic Release.
For now the manual trigger is not supported in YAML pipeline, see this discussion. Good news is that the Product team has considered the feature request and the new feature is on Roadmap. (Perhaps on plan for 2020 Q3)
According to the team there: The scope of new feature they are thinking here is to be able to mark a stage as "always start manually". If there are other stages that depend on this stage, then those would continue to wait till this stage has executed.
We may have to wait for some time before the manual trigger feature comes true in Yaml pipeline. Hope the new feature would meet your needs.
Microsoft says that their teams internally use Release Flow branching strategy: Release Flow: How We Do Branching on the VSTS Team
Release Flow means that the release branch has to be created to make the release triggered, which can look this way:
releases/productname-sprint02
Therefore, creation of a such branch can act as the manual trigger
In multi-stage YAML pipeline the production deployment stage should be coded to be triggered when the pipeline execution is the release branch context, which is not hard to do using a condition: and an expression that contains a check:
${{ startsWith(variables['Build.SourceBranch'], 'refs/heads/releases')
p.s. My recent blog on the similar subject: Azure DevOps – YAML pipelines and branching strategies
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.