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
Recent posts

Azure DevOps YAML based CD pipeline with multiple artifacts

In my post called " Switch from Azure DevOps release pipeline to YAML based CI/CD pipeline " I explained how to implement a combined CI/CD pipeline based on YAML templates. Because most of the deployments in my daily work are consuming multiple artifacts I had to do some additional R&D to find a solution for those releases in Azure DevOps. Base structure In the first post about the transition to YAML CI/CD pipelines I introduced the base structure. The templates I want to reuse are added to the yaml-template folders in the root of my GIT repo. For the CD pipelines which lack a CI phase I introduce a new folder called yaml-releases which will contain the YAML files for releases which are based on multiple artifacts. The folder structure within my GIT repo is thus: yaml-releases releaseArea myMultipleArtifactsRelease azure-pipelines.yml cd-job.yml yaml-templates jobs ... templates ...

Switch from Azure DevOps release pipeline to YAML based CI/CD pipeline

It has been years ago I started applying continuous integration (CI) and continuous deployment (CD) principles at work. Around 2005, it was the time of Visual Studio 2005 Team System, we started using a build server in our daily development process. From then on it was no longer more: "it works on my machine". With every check-in of code changes a CI build was started which compiled your code and run unit tests which verified the quality of your code.  Deployment was in the beginning still a process of manually copying build artifacts and script files to servers and doing the installation process based on the instructions from the deployment manual (if available). Gradually it migrated to scripts (mix of batch/PowerShell/VBScript files) that our release automatically ran from the build server. In 2016 we migrated from our on-premise TFS 2008 based environment to the cloud solution nowadays known as Azure DevOps . We upgraded our MSBuild driven CI/CD pipelines to the new vis

Subnet delegation and API Management

When updating some network related ARM templates I stumbled on the concept of subnet delegation. What is subnet delegation? Subnet delegation enables you to designate a specific subnet for an Azure PaaS service of your choice that needs to be injected into your virtual network. When you delegate a subnet to an Azure service, you allow that service to establish some basic network configuration rules for that subnet, which help the Azure service operate their instances in a stable manner. One of the advantages is that the service can configure for example routing policies or network security groups.  Subnet delegation and API Management When I was updating our virtual network/subnet templates I stumbled on the delegation section. "delegations": [ { "id": "string", "properties": { "serviceName": "string" }, "name": "string" } ] After doing some research about the concept I opened

Solved Windows 10 20H2 update screen resolution issue: ultrawide monitor connected to Microsoft Surface Dock

 Today I received the Windows 10 version 20H2 update on my corporate Microsoft Surface. After rebooting I had screen resolution issues on my external Dell Ultrasharp 3419W  ultrawide monitor which was connected to the Surface Dock . Instead of the 3440x1440 resolution my monitor started with a 1024x768 resolution. When I tried to change the resolution back to the 3440x1440 setting I noticed that the highest supported resolution was 1280x1024. When I connected the monitor directly to the Surface the native resolution of 3440x1440 was back. Updating and removing the general monitor driver did not help either. When I downgraded back to Window 10 2004 the problem was gone and support for 3440x1440 was back on the Surface dock. I finally figured out how to solve the issue between the Surface dock and Windows 10 20H2. I downloaded the official Dell driver for my monitor and changed the generic driver to this Dell U3419W driver . Then I reinstalled the Windows 10 20H2 feature update and when

Get values from linked ARM template with a copy loop

The Microsoft documentation for modularizing ARM templates is missing a sample where the copy loop is combined with returning output. I modified the example template which Microsoft uses in their Get values from linked template example to demonstrate this scenario.  The linked template gets a parameter where we can pass in a name for the greeting. { "$schema": "", "contentVersion": "", "parameters": { "name": { "type": "string" } }, "variables": {}, "resources": [], "outputs": { "greetingMessage": { "value": "[concat('Hello ', parameters('name')]", "type": "string" } } } The main template deploys the linked template and gets the returned values from the name array. Notice th

Return the correct Content-Type for a Logic App API in API Management

Given our company cloud strategy, BizTalk is finite for us and we have started the transition to an iPaaS landscape based on Microsoft Azure . The BizTalk environment is replaced by an environment consisting of API Management , Logic Apps , Functions , Event Grid and Service Bus parts. One of the BizTalk HTTP APIs is exposed by API Management to internal and external consumers and is partly migrated to a Logic App already. This transformation to iPaaS should have no impact on the consumers of the API Management endpoints.  Sadly we found out this week that this was not true for one of the methods within that specific API. One of the consumers was transitioning from the BizTalk API to the version hosted in API Management. When testing the API they complained that the received an error that the HTTP Header Content-Type was not supported in their client. The value they received was application/xml instead of the BasicHttpBinding value text/xml; charset=utf-8 they needed. The develope