Even after setting the SDK to 3.1 there will be a failure running dotnet ef migrations script command and any dotnet ef command.
--------------------------------------------------------------------------------------
Could not execute because the specified command or file was not found.
Possible reasons for this include:
* You misspelled a built-in dotnet command.
* You intended to execute a .NET Core program, but dotnet-ef does not exist.
* You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
##[error]Cmd.exe exited with code '1'.
This is due to that the EF tool comes as a separate NuGet package in which is not available by default in hosted agents (Hosted Windows 2019 with VS2019 was used in this build).

To resolve this issue, you can install the dotnet ef tool to hosted agent by adding a command line step which is executing below command.
dotnet tool install --global dotnet-ef --version 3.1.2

Some teams when they practice Agile sprints keep a branch for the life of the sprint. In this case they do branch to develop features, make pull requests to sprint branch and release from the sprint branch at the end of the sprint. It is important to protect the sprint branch from incoming pull requests with policies. Since, there is no out of the box way to copy over the policies defined in one branch to another, each sprint the policies need to be created for the new sprint branch, which makes it a cumbersome process. In order to make it possible to copy set of policies defined in a branch to another, in Azure Git repos, now you can use the script made available here.

The script does below described actions.

The script takes the parameters listed below.

• $AzureDevOpsPAT: Personal Access Token having access to the code read, write and manage
• $OrganizationName: Azure DevOps organization name
• $teamProjectName: Team project name which contains the repository
• $repositoryName: Name of the Azure Git repository
• $fromBranch: Branch with the policies already setup
• $toBranch: Branch the policies should be copied to

'V4.7' is not recognized as an internal or external command, operable program or batch file.
Issue is caused by the | symbol used in the runtime value as it is special character in PowerShell allowing the piping of values. To prevent the issue, you can use below syntax by enclosing the runtime value with single quotes.

az webapp create -n app-chd5-test  -g rg-dotnet5-test -p asp-dotnet5-test --runtime '"aspnet|V4.7"'

Submodule in Git repos help you to keep the common code modules in a separate repo and utilize in multiple other repos. When you clone the git repo you can include submodules by using git clone --recurse-submodules. In Azure pipelines you can enable checking out the code with submodules for build and package purpose. Let’s have a look at the settings to enable submodule checkout in builds.

In the build, when you select an Azure Git repo you get the option to enable checkout submodules. It can be set recursive to checkout all nested submodules to checkout only the top-level submodule.

You get this option to checkout submodules in all Git based repos that can be used with Axure pipelines such as BitBucket, GitHub and other Git repos.

In YAML pipelines the syntax would be to use as shown below to checkout top-level submodules.

- checkout: self

submodules: true

To recursively checkout all nested submodules you can use the syntax below.

- checkout: self

submodules: recursive

Allow Azure services on Azure SQL Server lets other Azure Services such as function apps, app service apps etc. to be connected to an Azure SQL Server without needing to allow the outbound IPs of such services. You can enable this easily using the portal. Let’s look at how we can Allow Azure services suing CLI.

The Azure portal lets you switch on off the setting in the Azure SQL Server firewall settings page as shown below.

However, setting this to Yes using Azure CLI requires to get a firewall rule added with start and end IP set as 0.0.0.0

az sql server firewall-rule create -g myresourcegroup -s mysqlserver -n myallowazsvcrule --start-ip-address 0.0.0.0 --end-ip-address 0.0.0.0

To set the Allow Azure services to No you should delete the firewall rule as shown below.

az sql server firewall-rule delete -g myresourcegroup -s mysqlserver -n myallowazsvcrule

GitHub Actions are the CI/CD workflow implementation tool built into GitHub repos. While using the GitHub Actions workflows you may want to execute a cleanup, or rollback or even a ticket(issue) creation task in a situation where a job step is failed. In Azure DevOps pipelines each task had control support to easy implantations of the run on failure need. Let’s look at what it is in Azure DevOps then understand how we can achieve same goals in GitHub actions workflow steps.

In Azure DevOps pipelines you could easily achieve this type of a need in tasks by using control options.

In case of Azure DevOps YAML pipelines, the same set of control could be implemented the information from Microsoft docs (https://docs.microsoft.com/en-us/azure/devops/pipelines/process/tasks?view=azure-devops&tabs=yaml#conditions) is below.

In GitHub actions to execute a step in a job only when one of the previous step is failed you can use if: ${{ failure() }} in the step which needs to run on failure of previous step. For example, in below workflow we are purposefully failing a step by using exit code 1, and on the failure an issue in the repo is created using another step set to run at failures.

on: [push]

jobs:

  FailJobIssueDemo:

    runs-on: ubuntu-latest

    steps:

      - name: Step is going to pass

        run: echo Passing step

      - name: Step is going to fail

        run: exit 1

      - name: Step To run on failure

        if: ${{ failure() }}

        run: |

          curl --request POST \

          --url https://api.github.com/repos/${{ github.repository }}/issues \

          --header 'authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' \

          --header 'content-type: application/json' \

          --data '{

            "title": "Issue created due to workflow fialure: ${{ github.run_id }}",

            "body": "This issue was automatically created by the GitHub Action workflow **${{ github.workflow }}**. \n\n due to failure in run: _${{ github.run_id }}_."

            }'

The step created issue in the repository can be seen after workflow execution as below.

When you implement functions in Azure by default the routing is the https://functionappname/api/functionname . However, this implementation would not let you proper organizing of routing when you have multiple function apps in your software application project. You might want to create custom routing to make your function access from other application organized appropriately. Let’s look at default behaviors and how we can setup custom routing.

When you setup your fist function app in the resource group, say with name funct-sample01, and create two functions say func01 and func02, their default URLs would be as follows (note that anonymous access allowed in below functions).

https://funct-sample01.azurewebsites.net/api/func01

https://funct-sample01.azurewebsites.net/api/func02

Then if you create another function app named func-sample02, and create a function names func01, it would have below URL.

https://func-sample02.azurewebsites.net/api/func01

This is completely OK as long as your applications are going to call the functions directly. However, if you are going to use an APIM based routing, allowing the function app access via say Azure APIM (we can discuss about APIM routing and advantageous in a later post), you may want to alter function app rout prefix to add more than, /api/ which is the default rout prefix, to allow more clarity in routing.

If explained in other words both funct-sample01 and func-sample02 app have function named func01 which has routing setup as /api/func01, which might be creating confusions and misleading the consumers of the function.

https://funct-sample01.azurewebsites.net/api/func01

https://func-sample02.azurewebsites.net/api/func01

If we can make the above functions app routing to make the rout url for each function to add function app specific rout, that would avoid the confusion. For example, below urls would make more sense for the both function app above.

https://funct-sample01.azurewebsites.net/api/sample01/func01

https://funct-sample01.azurewebsites.net/api/sample01/func02

https://func-sample02.azurewebsites.net/api/sample02/func01

This make sample01 and sample 02 to have clear routing, distinguished from each other, and would be really help full in setting up App Gateway or APIM routing for additional protection.

To make this change what you have to do is in the host.json of the function app, setup the route prefix as specified in below syntax.

{

"extensions": {

  "http": {

    "routePrefix": "customPrefix"

  }

}

}

For funct-sample01, function app the rout prefix should be set as below.

{

"extensions": {

  "http": {

    "routePrefix": "/api/sample01"

  }

}

}

You can update Azure function app host.json from azure portal itself if required using app service editor or using kudus.

Once saved the host.json function URL updates as below.

Terraform is a great way to setup infrastructure as code (IaC) for Azure. Terraform helps us to codify and version control our infrastructure needs in multiple platforms, hence, making learning terraform for IaC for Azure would let an individual to easily get adapted to other platforms such as AWS. IN this post let’s have a quick look at preparing a Windows 10 machine to get started with terraform.

As the first requirement you may install the latest stable version of PowerShell, using the installer msi downloaded from here https://github.com/PowerShell/PowerShell. However, if you already have PowerShell version 5.1 or higher it should be sufficient. If you update to latest version of PowerShell 7 you will have a separate Windows PowerShell 7 app.

To check your version of PowerShell version you can run $PSVersionTable command.

Install PowerShell Az module.

Install-Module -Name Az -AllowClobber -Scope CurrentUser

Then run

Import-Module Az

To get the Az Module imported. Now if you execute a Get-Module you will see the Az module available to use in latest version of PS.

Install the latest version of Azure CLI following instructions here https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-windows?view=azure-cli-latest&tabs=azure-cli.

To check installed version of Azure CLI run az --version

Then download Terraform for Windows from https://www.terraform.io/downloads.html and extract to a desired path say c:\Terraform. Setup Path env variable to have new entry for Terraform path.

Execute Terraform from a new PowerShell window.

Now, we are all set with our Windows 10 machine to use Terraform development for infra as code, and in a next post let’s check how we can get some simple Azure platform services created using Terraform

We have discussed setting up a Windows 10 environment to develop terraform scripts in previous post. Let’s understand how to authenticate terraform to deploy infrastructure on Azure platform using a service principle with this post.

As the first step we need to have an SPN created in Azure. If you have more than one Azure subscription, make sure to set the required subscription in cloud shell using below CLI command.

Az account set --subscription azure subscriptionid

Service Principle (SPN) can be created in Azure allowing subscription level contribution permissions by executing below command in Azure cloud shell.

az ad sp create-for-rbac -n "infradeployapp" --role contributor --scopes /subscriptions/azuresubscriptionid

An app registration in Azure active directory will be created with contributor access to the subscription specified in the above command. The output of the SPN create will provide app id, password and the tenant information which you have to copy to a secure location, as the password will not be viewable again.

In terraform main.tf file you can add below code segment to allow authentication of terraform and authorize it to add resources to Azure subscription via the created SPN.

provider "azurerm" {

# The "feature" block is required for AzureRM provider 2.x.

# If you're using version 1.x, the "features" block isn't allowed.

version = "~>2.0"

subscription_id = var.AzureSubscriptionId

client_id = var.AzureSPNAppId

client_secret = var.AzureSPNPwd

tenant_id = var.AzureTenantId

features {}

}

The variables for the above setting can be defined in the variables.tf.

These variables can be supplied with command line so that the terraform is authorized to apply or execute plan on the given Azure subscription.

To supply each variable you can use syntax as below.

-var='variablename=variablevalue'

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.

Why I do not like it?

The Terraform commands allowing plan or applying a plan relies on a state file. To cater this need, Terraform task by Microsoft DevLabs demands to create Azure resource group, storage account, container and a key (terraform state file path). Which is to create a new env in Azure subscription the task demands to pre create few Azure resources manually.

When using Azure CLI based IaC for creating Azure resources only requirement was to have a service connection from the team project based on an SPN created in Azure in subscription level, to authenticate and authorize creating resources in Azure, which is reasonable prerequisite. However, keeping the terraform state in Azure storage account demands for every new subscription to have manual Azure resource creation work other than the SPN and service connection creation in Azure DevOps if the task by Microsoft DevLabs is used.

Couple of other Marketplace extensions evaluated as below and they seem to be not fixing the issue described above.

Terraform by Peter Groenewegen

This one still keeps state in Azure blob so demands to create Azure resources manually as a prerequisite.

Terraform by Jamie Phillips

Only allows installing Terraform.

Terraform by Tyler Evert

Relies on terraform state in an Azure blob storage demanding for pre-created Azure resources manually.

Terraform by Arkia Consulting

Not sure how terraform maintained with the tasks in this extension. Need an evaluation to confirm which we can do in another post.

What is the alternative?

As alternatives Terraform by Charles Zipp seems to have multiple approaches to store Terraform status, which can be used as a solution.

Out of options available with this task local option is not feasible to be used with hosted agent as keeping the terraform state locally in a hosted agent would not help in the subsequent runs. The azurerm options relies on Azure blob storage so it is not a solution. However, keeping self-configured and using state file as a secure file in Azure DevOps seems to be a possible solution which we can explore in a next post.

My own solution

As an alternative to using any of extension tasks I could come up with a solution described briefly below.

· Use Terraform Install task by Microsoft DevLabs to get terraform installed in the agent.

· Use PowerShell commands to create a plan and apply the terraform plan

· Store the terraform state and plans in Azure git repo via pushing the file to git repo with command line within PowerShell tasks.

· After executing plan the plan is stored in a git repo and manual intervention step with agentless phase to be introduced to verify plan and approve for applying.

· Add an apply plan agent phase utilizing state plan stored in Azure git repo.

With this solution an approval flow can be introduced as well utilizing the usage of terraform plan to find the changes getting applied to infrastructure and control it with an approval, so that better control on changes to infrastructure in an environment can be maintained. Let’s discuss this solution in detail in the next post.

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.

PowerShell Script to Execute Terraform Plan

To execute terraform via command line each variable must be passed in below syntax.

-var='variableName=variableValue'

Example: -var='envName=dev'

To build up such variables all parameters can be passed to PowerShell as params and then these parameters can be used to build the variable requirement syntax as shown below.

$joinChar='=';

# Set terraform variable with value

$AzureSubscriptionId='AzureSubscriptionId',$AzureSubscriptionId -join $joinChar;

The out come of above would be varibaleName=variableValue. The using these type of formatted variable in PowerShell for each parameter, terraform required variable passing syntax as a string can be built utilizing PowerShell script segment similar to below.

# Build up terraform variable format string

$varPrefix= "-var";

$vars =  ($varPrefix,("'",$AzureSubscriptionId,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$AzureSPNAppId,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$AzureSPNPwd,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$AzureTenantId,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$projectName,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$envName,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$prodEnvName,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$location,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$dotnetFramework,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$deploySlotName,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$planKind,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$planReserved,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$planSKUTier,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$planSKUSize,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$storageTier,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$storageReplicatonType,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$functionVersion,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$keyvaultPurgeProtection,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$SqlSvrVersion,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$SqlSvrAdminUser,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$SqlSvrAdminUserPwd,"'" -join '') -join $joinChar

       ),($varPrefix,("'",$SQLDatabaseEdition,"'" -join '') -join $joinChar

       ) -join ''

Above is just an example set of parameters. This can be altered based on the infrastructure creation need of yours. Outcome of above would be space separated string of parameters for terraform such as example below.

-var='AzureSubscriptionId=subsid' -var='AzureSPNAppId=appregid' -var='AzureSPNPwd=spnpwd' -var='AzureTenantId=tenatid' -var='projectName=qonsult' -var='envName=dev'

Next would be utilizing the parameter string build up the command for terraform plan and execute it via PowerShell.

# Set terraform plan file path and state file path parameters      

$outParam = '-out',("'",$planFilePath,"'" -join '') -join $joinChar

$stateParam = '-state',("'",$tfStateFilePath,"'" -join '') -join $joinChar

# Build up terraform plan command

$planCommand = 'terraform plan',$outParam,$stateParam,$vars -join ''

write-host ($planCommand)

# Execute terraform plan

Invoke-Expression $planCommand

Full script sample can be found here, which can be used with your own parameters (sample parameters defined) based on your need of infrastructure.

Execute Terraform Plan with Azure Pipeline and Store State and Plan in a Repo

As next step terraform can be installed to the agent machine and set the path for enable execution of command line terraform commands. This can be done via Install Terraform task by the extension of Microsoft DevLabs.

Once the package downloaded and extracted in the same package extracted folder need to create a folder and clone the repo which contains the terraform state and plans. This could be empty repo just containing the InfraRelease folder.

The cloning can be performed with below PowerShell script.

$clonePath = '$(releaseDataRepoClonePath)';

$cloneUrl = '$(releaseDataRepoCloneUrl)';

$planFileFolderPath = '$(planFileFolderPath)';

md $clonePath

cd $clonePath

dir

git clone $cloneUrl $clonePath

If(!(test-path $planFileFolderPath))

{

New-Item -ItemType Directory -Force -Path $planFileFolderPath

}

dir

The clone repo url should be in the format of as shown below.

https://username:generatedpwd@dev.azure.com/devopsorgname/teamprojectname/_git/reponame

Then terraform init should be run to get the required terraform modules and plugins loaded so that the main.tf can be executed.

All these download package, install terraform to agent, clone the repo containing terraform state and plans, and initializing terraform can be created as pre task group and can be utilized for both Plan and Execute steps.

The plan step would contain above for tasks done as prerequisites and the execution of terraform plan via the PowerShell script described previously.

The execution should happen from the extracted package path which is having the PowerShell script, main.tf and varaibles tf, and contains a folder with cloned repo where the state and plan files may exist if the command is running after any initial executions. Correct plan file path and state file path, which would be inside cloned repo, should be provided to the PowerShell script.

After execution plan execution is completed a new plan file would be added and the repo should be pushed with the changes. This need can be achieved via another PowerShell script as shown below.

$clonePath = '$(releaseDataRepoClonePath)';

$envName='$($envName)';

cd $clonePath

dir

git config user.email "$(gitUserEmail)"

git config user.name "$(gitUserName)"

# Upload plan file and state file to repo

$commitMessage = "Add terraform plan and state for env",$envName,"for release",$env:RELEASE_RELEASENAME -join ''

git add .

git commit -m "$commitMessage"

git push

The step will be executed from the extracted cloned repo path.

In summary following are the steps.

· Download main.tf, varaibles.tf and terraform plan execution PowerShell to a folder

· Install terraform in the agent

· Clone the terraform state and plan file repo to folder in path where the main.tf etc. extracted

· Execute a terraform init command from the location of main.tf to ensure plugins and modules are loaded.

· Execute the terraform plan supplying terraform state path (state file may not exist in first execution and that is not an issue) and path to save plan. These paths should be in the cloned repo.

· Push the new plan added to the Azure Git repo

Once above steps executed the plan to be applied can be viewed in the log of Azure DevOps pipeline.

In the next post let’s understand how to add the manual intervention step and wait for approval of plan by viewing the plan in the log as shown above, and get the same terraform plan executed with the pipeline.

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.

Terraform plan can be viewed in the release logs as explained in the previous post. Once the plan is uploaded to an Azure Git repo it is possible to complete the agent job and utilize an agentless job in the pipeline to use a manual intervention task. Such Manual intervention task will allow the approver to check the plan in the log or from the uploaded plan file (need to convert the plan to viewable Jason using tools such as terraform plan parser).

Once the approver is happy with plan it is possible to approve or if unhappy can reject further execution of the pipeline.

Once the approval is given the next steps to be executed in another hosted agent job. As a prerequisite need to download the package which is containing the main.tf and the variables.tf and extract it. Then Install the terraform should be installed in the agent machine utilizing the Microsoft DevLabs extension task to install terraform. The next step would be to clone the Azure Git repo containing the plan and optionally the terraform state of the target environment (first execution will not have the state). Next the terraform init command should be executed to get the required terraform modules and plugins loaded. All these steps were describe n detail in the post “Azure Terraform Infra as Code Deployment via Custom PowerShell with Azure DevOps Pipelines – Part 1 – Create Plan”.

Once these prerequisites are ready in the agent job the next step would be to use a simple PowerShell task to execute Terraform Apply using the plan. Below script can be used for the purpose of applying the plan cloned from the Azure Git repo. It is required to pass the terraform state file path (even if no state file in the first run after apply command the file will be created), and the plan file path already available in the cloned repo folder. The task working directory should be set to the package extracted folder which contains the cloned repo content as well in a folder.

$tfStateFilePath = '$(tfStateFilePath)';

$planFilePath = '$(planFilePath)';

# Set terraform state file path parameters

$stateParam = '-state',("'",$tfStateFilePath,"'" -join '') -join '='

# Build up terraform apply command

$applyCommand = 'terraform apply',$stateParam ,$planFilePath -join ''

write-host ($applyCommand )

# Execute terraform apply

Invoke-Expression $applyCommand

Once the plan is executed successfully state would be saved in the cloned folder Azure Git repo path. It is required to update the Azure Git repo with the terraform state file so that in the next release, the state file can be utilized to execute next plan with any modification to the target environment Azure infrastructure. How to push the changes was described via Git command line in a PowerShell task was described in the post “Azure Terraform Infra as Code Deployment via Custom PowerShell with Azure DevOps Pipelines – Part 1 – Create Plan”.

Once pushed the terraform state would be available in the repo for next infra run cycle. This implementation eliminates the need to keep the terraform state in another Azure resource such as storage account, which is making only prerequisite to deploy to a new subscription (in QA, UAT or Production environment needs), would be to have an SPNN created to make necessary connectivity.

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.

You can use couple of key words in the description of the pull request to specify the state. It could be state name and the work item would be set to the state. If you put the state category name work item state would be set to the first state of the category. Below table from Microsoft documentation shows the possible keyword to use.

Once the pull request is completed and merged you would be able to see the states changed as below. Notice while all user stories are closed but the bug work item is moved to resolved as described in the table from MSFT docs.

The user story shows the state change to closed due to the pull request completion.

Similarly, the bug work item history is showing due to the pull request completion the bug is moved to resolved state.

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.

A pipeline can be set as trigger to another pipeline using the syntax below. The simplest implementation would be specifying the resource pipeline name as source (which is the name you set for the pipeline in the Azure DevOps portal). Then specify an identifier as pipeline to use any additional resources such as build artifacts available in the source pipeline (We will discuss usage of the pipeline artifacts in another pipeline with YAML in a next post). If the source pipeline is from a different team project you can specify the source team project as well. Then setting the trigger as true will allow the pipeline to be triggered once the source pipeline execution completes.

Below is a full demo pipeline using a dummy stage to execute as Dev environment deployment based on the build pipeline completion. Build pipeline is an ASP.NET Core 3.1 web app build which is a YAML pipeline.

Source Pipeline - App.CI

CD Pipeline – App.CD

In addition to just specifying to trigger when source pipeline is completed you can enhance the trigger with filters, such as to trigger the CD YAML pipeline if the build pipeline is based on a given branch pattern. It is possible to use include as well as exclude filters for branches.