CODEWITHSUNDEEP
azureazure-devopsazure-pipelinesdevops
Azm
Azm

Reputation: 111

How to deactivate/Skip stage in release pipeline(non YAML) but its passthrough(continues for next stages)

from what I understand, in YAML pipelines you can select 'Stages to Run' and thus basically allow to skip stages entirely for whatever reason. However I do not see same functionality in the GUI release pipelines. I only see option 'Manual Only' - is 'Manual Only' usable in the scenario where I have dev > Test > Prod and I want to skip Test but keep the release pipeline structure intact? What is the best practice for this? So far I can see only option to have Both build and release in YAML.

Thanks.

Upvotes: 5

Views: 20903

Answers (2)

Edward Han-MSFT
Edward Han-MSFT

Reputation: 3185

If you use yaml pipeline having multi-stages, “Stages to run” feature allows you to skip a few stages in your pipeline as stated here: Skipping stages in a YAML pipeline.

If you want to implement this feature in classic release pipeline, please follow below steps.

  1. My release pipeline has 3 stages: Dev->Test->Prod, as below.

enter image description here

  1. Set a “RunTest” variable under Variables section for Test scope, and enable “Settable at release time” option, which can then allow us to change its value when running a new release.

enter image description here

  1. And then set custom condition: eq(variables['RunTest'], 'true') for Agent job in Test stage, as below.

enter image description here

  1. Therefore, if we want to skip Test stage in new release, just change its value to false, as below.

enter image description here

Upvotes: 10

Trent Tamura
Trent Tamura

Reputation: 1145

There are really a lot of ways to go about this, but the main ones I'll point out are:

#1 Single Release Pipeline with multiple stages/triggers

You were correct in thinking Manual deployment could work here using the various stages and branching out. (See Screenshot link below)

Release Pipeline with manual deployment paths

In this scenario DEV is deployed as soon as there is a new Release, then you can manually specify which path you want the rest of deployments to go (straight to Prod, or Test to Prod).

#2 Release Pipeline with pre-approvals

This is probably a little cleaner than the manual deployment and has the plus of being able to specify specific users or a group. (Link to screenshot below)

Release Pipeline with Pre-Approval condition

#3 Separate release pipelines executed based on build tag

After testing this I confirmed you are able to trigger varying releases based upon tagging specified in the Build Pipeline. I believe you can do the same for pull requests

Based on this tagging, it can determine through the Continuous Deployment filter process which release pipeline to run.

The Screenshot and steps below are the steps needed to make this work:

  1. Create Build Pipeline that includes whatever you need to successfully build, plus a Pipeline Variable (mine is ProdOnly_TestThenProd) that will be used to Specify the build tag name, and a Az Powershell task which will be used to set the Build tag on the build during execution. Here is the code for inline Script: Write-Host "##vso[build.addbuildtag]$env:ProdOnly_TestThenProd" Refer to this gif for reference: Build Pipeline
  2. Create two release pipelines one for DEV>PROD and another for DEV>TEST>PROD. Once created enable Continuous Deployment on Build and Add Branch/Tag filter based on your build pipeline branch/tag set. Refer to this screenshot: Release Pipelines
  3. Run the build pipeline manually and this will allow you to set the value of the pipeline variable at runtime, This allows you to specify which release pipeline you want to run in a one off situation, otherwise, the build pipeline can run with whatever the current variable value is in the Continuous Integration process. refer to this gif for illustration: Build Pipeline execution and Continuous Deployment

I like this #3 option because it allows you to have CI/CD cycle, but also if you need to run a one off pipeline, maybe release straight to Prod or some other stage, then it gives you flexibility to do so without a ton of manual work. Hopefully this answers your question.

Upvotes: 3

Related Questions