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
Azure Feeds used to be scoped to an organization. However, to enable public feeds and to become more consistent with the rest of Azure DevOps, feeds created through the new create feed UI are now project-scoped.
The only way to create an org-scoped Azure Artifact Feed is through API calls and it’s not reccomended.
If we want to share a feed with an entire organization this is what we need to do.
The Microsoft Visual Studio Setup Project is an old technology to create installer developed by Microsoft. It is out of support from nearly a decade and not present in Visual Studio anymore but when I visit customer sites I find legacy technologies and I need to deal with it on the short-term.
A couple of days ago I was working on an automated CI build on Azure DevOps and we hit an issue when trying to compile an old VDPROJ (migration to Wix in progress, btw ☺). We encountered an HRESULT 8000000A error.
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.