Tag Archives: Azure DevOps

Azure Pipelines YAML hidden UI for parameters as input

The Azure Pipelines is the feature of Azure DevOps that allows you to automate your build and release processes, to unleash the full potential of CI/CD practices.

Pipelines can be simple or complicated but, it’s very likely that you need to specify some kind of input to a Pipeline just before starting it.

Classic Pipelines

This is where variables come to help when you’re using the classic version of Azure Pipelines. Inside the Variable tab you write variables and then you can set if it’s “settable at queue time”. This way, when you start the pipeline, a slice of UI will provide a prompt to complete. The input is treated as a string and you can’t do much more.

Option to set a variable at queue time.

YAML Pipelines – This is where magic happens!

If you’re trying to achieve the same thing with YAML pipelines you can rely on the power of parameters. Actually, you can achieve more with YAML pipelines!

Runtime parameters let you have more control over what values can be passed to a pipeline. With runtime parameters you can:
– Supply different values to scripts and tasks at runtime
– Control parameter types, ranges allowed, and defaults
– Dynamically select jobs and stages with template expressions


Because parameters are explicitly typed you can create a better user experience for users of your pipelines with a fully featured UI with check-boxes, radio-buttons and text areas. You can do this in 3 easy steps. Open your YAML definition and for each one of the inputs that you need:

  1. Create a parameter
  2. Specify a default value
  3. Specify allowed values

This an example of a YAML Pipeline definition that accepts a string as an input to complete the famous “Hello World” greeting but, within a set of specific allowed values. Also, the default value is set to world.

  - name: myString
    displayName: string
    type: string
    default: 'world'
    - world
    - mondo

  vmImage: 'ubuntu-latest'

- script: echo Hello, ${{ parameters.myString }}!
  displayName: 'Run a one-line script'

When you Run the pipeline the UI shows specific fields to collect your input (greetings in our example).

The Run Pipeline dialog with additional parameters.

I suggest you to try with all the parameters type that the YAML schema provides. This is a complete example showing all the available options:

  - name: myParameter
    displayName: greetings
    type: string
    default: 'world'
    - world
    - mondo
  - name: myNumber
    displayName: 'Number'
    type: number
    default: '1'
    - 1
    - 2
    - 3
  - name: myBoolean
    type: boolean
    default: true
  - name: myObject
    type: object
      foo: FOO
      bar: BAR
      - one
      - two
      - three
        one: apple
        two: pear
        count: 3
  - name: myStep
    type: step
      script: echo my step
  - name: mySteplist
    type: stepList
      - script: echo step one
      - script: echo step two

  vmImage: 'ubuntu-latest'

- script: echo Hello, ${{ parameters.myParameter }}!
  displayName: 'Run a one-line script'

The resulting UI is:

Isn’t this awesome?

The power of the community

Thanks to my friend Giulio Vian of getlatestversion.it for the heads-up about this feature. The official Microsoft doc lacks a detailed explanation of this specific usage of YAML Pipelines parameters!

IIS XML Transformation with Azure DevOps

I was preparing a demo about IIS XML Transformation inside a CD pipeline with Azure DevOps.

It’s very likely that if you’re working with an ASP.Net project with default values the Azure App Service Deploy Task will fail. After some googling I found that this is documented here.

The trick is to remove the <DependendUpon> tag inside the csproj file.

By default, MSBuild applies the transformation as it generates the web package if the <DependentUpon> element is already present in the transform file in the *.csproj file. In such cases, the Azure App Service Deploy task will fail because there is no further transformation applied on the Web.config file. Therefore, it is recommended that the <DependentUpon> element is removed from all the transform files to disable any build-time configuration when using XML transformation.

File transforms and variable substitution reference, XML transformation notes, Microsoft Docs

How to configure access policies to Work Items on Azure DevOps

One of the strengths of Azure DevOps is that it’s very scalable. It can be configured to work for company of all sizes: from small teams of a few people, to a large enterprise with thousands of users.

When we work in complex environment we should follow the best practices to choose how to organize people and projects on our Azure DevOps Organization. This is a great piece of documentation to get started when we work in an enterprise scenario and I recommend reading it.

A general (but please double check if it is suitable for your environment) guideline is to work inside a single project and create many teams.

With this kind of setup is common that customers ask me to provide a way to limit visibility of work-items. This way only some people could access some work items. This is to provide better focus to teams, for example. But your project could have other needs to do this.

Continue reading

Reduce your build time with parallelism in Azure DevOps

Your team works with a project in Azure DevOps. Your build time starts to increase as the project’s complexity grows but you want your CI build to deliver results as quickly as possible. How can you do that? With parallelism, of course!

Let’s do this together.


Before we start to design a build pipeline with parallelism we must be aware of how Azure DevOps orchestrate parallelism and how many parallel jobs we can start. I recommend to read the official Microsoft Docs page about this.

Designing the build

The following example shows how to design a build with:

  1. A first “initialization” job.
  2. The proper build jobs: build 1 and build 2 that we want to run in parallel after the step 1.
  3. A final step that we want to execute after that build 1 and build 2 are completed.

We start with configuring the build to look like the following picture:

To orchestrate the jobs as we specified before we use the “Dependencies” feature. For the first job we have no dependencies so leave the field blank.

For the Build 1 job we set the value to Init. This way we’re instructing Azure DevOps to start the Build 1 job only after that Init has completed.

We do the same thing with the Build 2 job.

For the final step we set Build 1 and Build 2 as dependencies so this phase will wait for the 2 previous builds to complete before starting.

Here we can see the build pipeline while it’s executing.


With this brief tutorial we learned how to design a build pipeline with dependencies and parallelism that can reduce the delay of our CI processes. A fast and reliable CI process is always a good practice because we must strive to gather feedback as quickly as possible from our processes and tools. This way we can resolve issues in the early stages of our ALM, keeping the costs down and avoiding problems with customers.

Azure DevOps – Undelete a Release Pipeline

A few months ago I deleted a folder with inside a release definition.
My friend Alessandro Alpi helped me a lot pointing me to this msdn article.
With the PowerShell script that you find following the link you can restore a deleted release pipeline but only within 4 weeks of the deletion.

Continue reading