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.
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.
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:
Create a parameter
Specify a default value
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.
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
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.
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.
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!
The following example shows how to design a build with:
A first “initialization” job.
The proper build jobs: build 1 and build 2 that we want to run in parallel after the step 1.
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.
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.