Skip to main content

Make steps conditional in multi-stage YAML pipelines

To make the switch from the graphical release pipelines in Azure DevOps I am missing two features. The first one is to be able to defer a deploy and the second one is to exclude certain deployment steps without the need for editing the YAML file. 

The defer option is something Microsoft has to solve in their Azure DevOps proposition. It's a feature which you have in the graphical release pipeline but what they have not implemented yet in their YAML pipeline replacement. Approvals and certain gate conditions are implemented on the environment but the defer option is still missing

Pipeline

The conditional deployment option can be implemented with the help of runtime parameters and expressions. In the parameter section you define boolean parameters which will control the deploy behavior. With the expressions you can control which stage/job/task should be executed when the pipeline runs.

In the below YAML sample I experimented with conditions in the azure-pipelines.yml file directly for the CI phase and for the CD phase I used the templated solution I posted earlier about. In that case I have to passthrough the collected deployment instructions collected in the UI (or use the default values). To keep the templates generic I construct an object to passthrough the information to the correct job template which know how to use the deployment sequence logic.

# Build numbering format
name: $(BuildDefinitionName).$(Year:yy)$(DayOfYear)$(rev:.r)

parameters:

- name: deployArtifact1
  displayName: 'Deploy: Artifact 1'
  type: boolean
  default: true

- name: deployArtifact2
  displayName: 'Deploy: Artifact 2'
  type: boolean
  default: false

- name: deployArtifact3
  displayName: 'Deploy: Artifact 3'
  type: boolean
  default: true

# Pipeline trigger
trigger: none # Opt out of CI triggers

stages:

# CI phase
- stage: ci
  displayName: Build
  jobs:
  - job: validateAndPackage
    displayName: 'Conditional building'
    steps:
    - checkout: none # Suppress check out source code

    # Build sequence
    - ${{ if eq(parameters.deployArtifact1, true) }}:
      - task: CmdLine@2
        displayName: 'Build 1'
        inputs:
          script: echo pipeline level - building 1 - ${{ parameters.deployArtifact1 }}

    - ${{ if eq(parameters.deployArtifact2, true) }}:
      - task: CmdLine@2
        displayName: 'Build 2'
        inputs:
          script: echo pipeline level - building 2 - ${{ parameters.deployArtifact2 }}

    - ${{ if eq(parameters.deployArtifact3, true) }}:
      - task: CmdLine@2
        displayName: 'Build 3'
        inputs:
          script: echo pipeline level - building 3 - ${{ parameters.deployArtifact3 }}

# CD phase
- template: cd-stage.yml
  parameters:
    artifactObject:
      artifact1: ${{ parameters.deployArtifact1 }}
      artifact2: ${{ parameters.deployArtifact2 }}
      artifact3: ${{ parameters.deployArtifact3 }}

Stage template

As described in the pipeline section the stage receives an object with the collected information and it is only passing through the object to the job template.

# cd-stages.yml

parameters:

# Indicates which artifacts to deploy
- name: artifactObject
  type: object

stages:

  # CD phase - deploy only feature branches
  - stage: cd
    displayName: Deploy
    jobs:
    - template: cd-job.yml
      parameters:
        artifactObject: ${{ parameters.artifactObject }}

Job template

This simplified job template receives the instructions for the deployment sequence via the artifactObject parameter. In the condition expressions for each task we check if the task has to be executed.

# cd-job.yml

parameters:

# Indicates which artifacts to deploy
- name: artifactObject
  type: object

jobs:
- deployment: deploy
  displayName: 'Conditional deployment'
  pool:
    name: Default
  environment: Sandbox
  strategy:
    runOnce:
      deploy:
        steps:
          - checkout: none # Suppress check out source code

          # Deploy sequence
          - ${{ if eq(parameters.artifactObject.artifact1, true) }}:
            - task: CmdLine@2
              displayName: 'Deploy 1'
              inputs:
                script: echo job level - deploying 1 - ${{ parameters.artifactObject.artifact1 }}

          - ${{ if eq(parameters.artifactObject.artifact2, true) }}:
            - task: CmdLine@2
              displayName: 'Deploy 2'
              inputs:
                script: echo job level - deploying 2 - ${{ parameters.artifactObject.artifact2 }}

          - ${{ if eq(parameters.artifactObject.artifact3, true) }}:
            - task: CmdLine@2
              displayName: 'Deploy 3'
              inputs:
                script: echo job level - deploying 3 - ${{ parameters.artifactObject.artifact3 }}

Comments

Popular posts from this blog

CS8357: The specified version string contains wildcards, which are not compatible with determinism.

Today I was busy with creating a WCF service solution in Visual Studio Enterprise 2017 (15.9.2). In this solution I use a few C# class libraries based on .NET 4.7.2. When I compiled the solution I got this error message: Error CS8357: The specified version string contains wildcards, which are not compatible with determinism. Either remove wildcards from the version string, or disable determinism for this compilation The error message is linking to my AssemblyInfo.cs file of the Class library projects. In all the projects of this solution I use the wildcard notation for generating build and revision numbers. // Version information for an assembly consists of the following four values: // // Major Version // Minor Version // Build Number // Revision // // You can specify all the values or you can default the Build and Revision Numbers // by using the '*' as shown below: // [assembly: AssemblyVersion("1.0.*")] [assembly: AssemblyVersion("1.0.

Fixing HTTP Error 401.2 unauthorized on local IIS

Sometimes the Windows Authentication got broken on IIS servers so you cannot log in locally on the server. In that case you get the dreadfully error message HTTP Error 401.2 - Unauthorized You are not authorized to view this page due to invalid authentication headers. To fix this issue you can repair the Windows Authentication feature with the following PowerShell commands: Remove-WindowsFeature Web-Windows-Auth Add-WindowsFeature Web-Windows-Auth

Deploy with ARM templates an Azure DevTest Lab environment

Within the company I work for we use Azure DevTest Labs already for a year to host our personal development computer and the BizTalk CI machines we need. We are planning to host also our development and test environments in Lab environments. At the moment we configure the lab environments manually. I invested some time to write ARM templates to deploy Azure DevTest Labs within 5 minutes based on Azure DevOps CI/CD pipelines. In the process of writing these scripts I learned a lot. For example that the Azure documentation is not always up to date and that includes also tooling like Azure Resource Explorer . Based on querying the REST API with Postman I found the missing pieces for deploying a DevTest Lab environment based on nested ARM templates. In this post I will document the nested ARM template I created the last few days. Lab With the first template you can create the lab environment itself and configure the following parts of the environment Lab settings; like the st