Selecting Particular Source CI YAM Pipeline Build While Manually Triggering a YAML CD/Release Pipeline

In classic release pipelines in Azure DevOps you can pick which build to use in the linked build artifacts, easily at the create time. The new norm of implementing pipelines with Azure DevOps is becoming YAML way, allowing to keep your pipelines as code and version controlled. How to Separate CI and CD considerations to individual YAML pipelines was discussed in the post “Trigger Deployment YAML Pipeline Once YAML Build Completed”. Therefore, it is important to know how we can select a particular build, when we trigger a deployment/CD YAML pipeline manually. Let’s compare a classic pipeline triggering manually and YAML CD pipeline triggering manually to understand the difference.

Resolving “System.IO.IOException: The response ended prematurely.” in HttpClient Request

Some times a silly mistake can waste lot of time of a developer. The exception “System.IO.IOException: The response ended prematurely.” while making an http client request to call an API from another web app has wasted considerable amount of my time diagnosing the issue. Therefore, thought worth sharing the experience.

Prevent Checking Out the Repo in CD YAML Pipeline

In the previous post “Trigger Deployment YAML Pipeline Once YAML Build Completed” (https://chamindac.blogspot.com/2020/10/trigger-deployment-yaml-pipeline-from.html) we have discussed how to separate the deployment pipeline from the build pipeline, in Azure DevOps YAML pipeline implementations and to trigger a CD pipeline from the CI build once completed. However, if you check carefully that post implementation of CD it is still checking out the code repository, even though it is not necessary to checkout code being the deployment pipeline. Let’s see how we can avoid checking out repo in the CD YAML.

Trigger Deployment YAML Pipeline Once YAML Build Completed

Now it is possible to implement multi stage pipelines with YAML facilitating the implementation of deployment pipelines as well with YAML instead of classic release pipelines in Azure DevOps. However, having build and deployment steps all together in a single pipeline script is not ideal as it looks bit not a nice implementation from my point of view. With the possibility of triggering another YAML pipeline based on completion of another YAML pipeline, it is possible to separate the Build and Deployment concerns into two different YAML scripts implementing two different pipelines. Let’s have a quick look at how we can trigger a YAML deployment pipeline based on another YAML build pipeline.

Set Work Item State on Pull Request Completion

Associated work items help to identify what is completed in a given pull request. If required while completing a pull request you could, set the associated work item to be moved to completed state. With the introduction of new feature, which we are discussing in this post, you would be able to set the work item state (regardless of it is associated work item or not for the pull request) to desired closed, in progress or resolved states based on description specification.

Azure Terraform Infra as Code Deployment via Custom PowerShell with Azure DevOps Pipelines – Part 2 – Execute Plan with Approval

In the previous post “Azure Terraform Infra as Code Deployment via Custom PowerShell with Azure DevOps Pipelines – Part 1 – Create Plan” we have discussed how to generate a terraform plan targeting Azure Infrastructure deployment and upload it to an Azure Git repo. The solution is implemented instead of using terraform task for Azure DevOps, which is available with Microsoft DevLabs extension due to it is having a prerequisite of Azure resource group, storage etc. as described in the post “Why Azure DevOps Terraform Extension Task by Microsoft DevLabs to Deploy Infra to Azure Does Not Work for Me”. As the second part of previous post, let’s explore the steps require to approve the terraform plan and get the plan executed with Azure DevOps pipeline relying on a state kept in Azure Git repo instead of a storage blob, which is eliminating the need of having manually created Azure resources.

Azure Terraform Infra as Code Deployment via Custom PowerShell with Azure DevOps Pipelines – Part 1 – Create Plan

As described in the post “Why Azure DevOps Terraform Extension Task by Microsoft DevLabs to Deploy Infra to Azure Does Not Work for Me”, the Microsoft DevLabs task to plan and apply terraform infrastructure as code, is demanding to store state in Azure blob storage, which requires to create Azure resources manually as prerequisite of using the task. In this post let us look at a custom implementation of terraform plan and apply task utilizing PowerShell, while storing terraform state and plans in Azure Git repo and have an approval in between the plan and apply steps, to enhance the deployment workflow.

Why Azure DevOps Terraform Extension Task by Microsoft DevLabs to Deploy Infra to Azure Does Not Work for Me

Terraform is used as declarative code for infrastructure deployments on multiple cloud platforms including Azure. Azure DevOps provides capability to execute Infrastructure as code (IaC), with CI/CD pipelines, by using tasks added with the extension by Microsoft DevLabs (https://marketplace.visualstudio.com/items?itemName=ms-devlabs.custom-terraform-tasks) available in the marketplace. The terraform task to plan or apply a terraform plan demands to have reources in Azure such as a resource group, storage account, container and a key (terraform state file path). Similar demands are there for even AWS and GCP for when using the task.