Pass Map Type Parameters to Terraform via Azure Pipelines

Terraform based resource deployment to Azure is a great way to implement infrastructure as code. The map type in variables support implementing loop-based resource deployment specifications in terraform. It is important to understand passing such variable as parameter in command line to implement pipelines.

New Manual Validation Task for YAML Pipelines

Even though YAML pipelines could be setup to wait for approvals based on environment approvals and checks, setting up a manual intervention task which was available to classic release pipelines, was not supported in YAML deployment pipelines till the latest feature release to Azure DevOps. With the introduction of new Manual Validation Task specifically supporting only YAML pipelines, now you can wait for resume/reject with an agentless job, during the YAML pipeline execution. Let’s look at how this new task works.

Obtaining Build Number, Build Id etc. of Another CI Build Pipeline in the CD/Release YAML Pipeline

Let’s look at how we can specify the artifact version to download based on the resource CI build linked to the CD pipeline and check on how to obtain the resource CI build pipeline information such as build number, build id definition id etc., in the CD YAML pipeline.

Implementing a CD YAML Pipeline with Deployment Job

We have discussed couple of things related to implementing CD with YAML in the posts “Trigger Deployment YAML Pipeline Once YAML Build Completed” and in “Prevent Checking Out the Repo in CD YAML Pipeline”. However, the checkout of the repo only happens if use the normal job syntax for deployment job as well. Ideally, we should be using job of type of “deployment” in our CD YAML pipelines so the checkout of repo would not happen by default as well as it will be required to define an environment for deployment. The environment helps us to keep track of our deployments. When we implement the CD YAML with deployment jobs download of artifacts would be automatic. Let’s find out how the deployment job implementation looks like.

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.

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.

Deploying Infrastructure to AWS Lightsail Using Azure DevOps – Part 3 – Creating a Release Pipeline to Deploy AWS Lightsail Infrastructure

In the previous two post, we have discussed how to write a bash script with AWS CLI to create AWS Lightsail instance and, how to setup a service connection in Azure DevOps for AWS. IN this post, lets explore the steps required to get the bash script executed in a release pipeline to create AWS Lightsail infrastructure.

Deploying Machine Learning (ML) Model with Azure Pipeline Using Deployable Artifact from Build

We have discussed how to create a Machine Learning (ML) model as a deployable artifact in the post “Training Machine Learning (ML) Model with Azure Pipeline and Output ML Model as Deployable Artifact” which is based on the open source ML repo, (https://github.com/SaschaDittmann/MLOps-Lab.git) with data by Sascha Dittmann, which also contains the code to train a model.

Creating an Azure Web App Supporting .NET Core 3 – IaC with Azure Pipelines

We have discussed how to build a .NET Core 3 Web Application in the previous post. In order to deploy a .NET Core 3.0 Web App to an Azure Web App, you need to install .NET Core 3.0 Extension to the Azure Web App. You can easily add .NET Core 3.0 via Azure Portal to a Web APP. However, if you are really into automating your infrastructure as code (IaC) you may want to make all these steps automated and executed via a deployment pipeline. Let’s look at a script which is using Azure CLI and Azure PowerShell to fully automate creation of a .NET Core 3.0 enabled Azure Web App.
You can download the full script from here. Let’s understand each part of the script.

Azure DevOps Service Connection for an Azure Subscription in Another Azure AD

Adding Azure Subscription to Azure DevOps  as service connection is really simple when you have the same account you are using for Azure DevOps associated with your Azure Subscription. However, this may not be the case always and you may want to deploy to resources in a Azure Subscription which is not related to your Azure DevOps organization. Let’s see how to create a service connection in such situation to utilize it in a deployment pipeline.

Setting a Release Variable to Make It Available to Other Stages in Azure DevOps Release Pipeline

You can easily set a variable in a build or release pipeline by executing “##vso[task.setvariable variable=variablename;]variablevalue” . This sets the variable for the scope of a given stage in a release pipeline. However, it does not allow you to set a variable in the scope of a release. That means if you want to set a variable value in stage and then use it in subsequent stages it is not possible to do it with  ##vso[task.setvariable . Let’s look at achieving this need using Azure DevOps REST API.
The script available here can be used for this purpose. A slightly modified version of the script to support release pipeline and enable sending any variable name and value for updating a value of a given variable can be found here.

Deploying ASP.NET Core App to Azure Kubernetes Services (AKS)–Setting Up Azure DevOps Pipeline Manually–Step By Step Guide–Part 2

In the part 1 of this post, enabling Docker support for ASP.NET Core app and building and pushing the Docker image to Azure Container Service, using Azure DevOps build pipeline with simple steps was described. The image is tagged with the build Id and it is pushed to the Azure Container Registry, so that it can be later deployed to a container orchestrator to run the container. Helm is used to get he deployment done to AKS via Azure DevOps when creating a an ASP.NET Core App, Container Registry and AKS, then getting it deployed automatically with few clicks using Azure Projects as described in the post “Deploy ASP.NET Core App to AKS with Azure DevOps Project”. Let’s look at getting the container image in Azure Container Registry deployed to AKS with three simple steps without using Helm, with Azure Pipelines.

Controlling Octopus Releases with VSTS Release Management

You may be using Octopus deploy for your deployment automation pipeline needs while you are having your builds and work items managed in VSTS. It is a good idea to manage the Octopus release pipeline via VSTS release management so that you have the opportunity to use automated test execution and capturing of test results, as well as easily generate release notes using the VSTS work items, using feature rich tasks and automation test results views in VSTS release management. Let’s look at the important steps required to make VSTS release management to successfully utilize your existing Octopus deploy process steps.

Securing Release Definitions When Multiple Teams Work on a Single Team Project

We have explored “Securing Build Definitions When Multiple Teams Work on a Single Team Project” in a previous post. Now the folders to group release definitions and applying permissions to isolate each team’s release definitions is also a possibility in VSTS. As we discussed in the “Securing Build Definitions When Multiple Teams Work on a Single Team Project” it is important to create the Build/Release admins VSTS permission group for each of the teams in the team project. Using the same admins group and the team we can setup permissions for release definitions folders. Let’s look at the steps in detail.

New Release Definition Editor–Team Services

Release definition in Team Services helps you to define deployment pipelines across target environments. You can setup a release definition to deploy via agents, deployment groups or execute agent less activities. With the latest update to Team Services a new release definition editor is introduced. Let’s ex[lore the new editor.

Deployment Groups in VS Team Services

Deployment groups provide robust out-of-the-box multi-machine deployment with team services release management. It allows you to run deployments across multiple machines. You can install agent on each of your target servers directly and run rolling deployment to those servers, unlike agent based deployments where you install build/deployment agents on proxy servers in an agent pool. You can use all tasks in task catalog on your target machines.

Deployment group allows you to create target deployment machine groups, without requiring you to register machines in agent pools or queues. Machine in a deployment group will have an agent registered with the named deployment group, within the team project providing required isolation for target environment (such as DevInt, QA, UAT, Demo, Production etc.), for a given product or project.

Logical group of targets (machines) having an agent installed on each of them is a deployment group. It represents your physical environments. It can be single-box, multi-machine or a farm of machines. You can specify the security context for your physical environments by using the deployment groups.

Let’s look at how to create a Deployment Group in Team Services.

Auto Generating CD Build/Release Pipeline Targeting Azure App Service for MVC Web Application

VSTS allows great flexibility with it’s new web based build and release management features. You have several templates which can be used to create build and release definitions you need quickly. Lots of out of the box tasks allow you to further customize your definitions to support the steps that you need to perform during a build or a deployment. Visual Studio Marketplace is getting more and more components added to it, allowing you to find a task for almost any build deploy step you may require to perform. Taking the steps to the next level, you can now even generate your build/release pipeline with Visual Studio 2017, after adding the extension Continuous Delivery Tools for Visual Studio.

Let’s walkthrough the steps of generating a CD pipeline for an MVC Web Application, to allow it to be deployed to Azure App Service.

Part 2 Deploy ASP.Net 4 Web Site - Deploying to Azure Web Site with Visual Studio Team Services Release

We have successfully built and produce downloadble build output in the Part 1 Build ASP.Net 4 Web Site. Let’s look at how we can setup a Release Pipeline with Visual Studio Team Services Release Management, to deploy this web site as an Azure Web Application.
Click green + to create a new release definition.
Select Azure WebSite deployment and click Ok in the dialog box.
This will create an environment with Azure Web App Deployment task. Rename the environment added to let’s say DevInt.
In the Artifacts tab of the release definition, click on Link an artifact source.
Select the build we have created in Part1.

In Azure Web App Deployment task set the parameters as shown below.
To link Azure Subscription to your VS Team Services Team Project follow the instructions here. Web App Name is the Azure Web App Name. Use the App Service Location as the Web App Location.

Select Deploy Package from linked artifact. How to publish build artifact is explained in Part1.
Trigger can be set to Continuous Deployment so that new artifact availability will trigger a deployment.
Approvers can be assigned but let’s keep it automated.

Let’s trigger a new build using build definition we have created in Part1.

Once the build done release automatically get triggered and get completed.


Site is getting deployed to Azure Web App.