Build triggers on Azure devops pipelines

Continuous integration (CI) triggers cause a pipeline to run whenever you push an update to the specified branches or you push specified tags. Build in triggers can become a powerful tool for your build strategy and the most common scenarios will be explained using the examples below.

Continuous integration triggers:

Branches:
Those will trigger your pipeline when a new commit is performed on your branch. In the scenario below the pipeline will run if code is merged on your main branch or a branch starting from releases like release1, release-1 releases etc. Also the pipeline will not run if a push is commited on uat branch. This is excluded through the exclude keyword.

trigger:
branches:
include:
- main
- release/*
exclude:
- uat

Tags:
Those will trigger your pipeline only when a tag is pushed on your repository. Tags are bound with a commit on a git source control system. In the scenario below the pipeline will get triggered if a tag is pushed following the v.* regex like v.1 , v.something, v.2 etc. Also it will not run if the tag that is pushed starts with uat keyword for example uat-1 will not trigger the pipeline.

trigger:
tags:
include:
- v.*
exclude:
- uat*

Pull Requests:
pr keyword will trigger your pipeline if a pull request is created from a branch and the destination is the noted one. For example if you create a new pull request from mybranch to current branch then the pipeline will get triggered. The pipeline will not trigger if a pull request is created from any branch to uat branch as it is excluded.

trigger:
pr:
branches:
include:
- current
exclude:
- uat

One powerful tool that you can combine with your build strategy is paths. When you specify paths, you must explicitly specify branches to trigger on. You can’t trigger a pipeline with only a path filter; you must also have a branch filter, and the changed files that match the path filter must be from a branch that matches the branch filter.

Paths:
Using a path you specify a directory/folder which will trigger the build. For example you may want only to trigger a build when particular files are changed on your repository. In the below example the pipeline will get triggered if files inside the docs folder change for the branches master and releases*

trigger:
branches:
include:
- master
- releases/*
paths:
include:
- docs
exclude:
- docs/README.md

Microsoft documentation for build strategies:

https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#ci-triggers

Create approvals on build and release Azure DevOps pipelines

On Azure devops you have the option to create both build and release pipelines. The build pipelines can be created using entirely the .yml notation in comparison with the release pipelines which should be created using a GUI. Build and release pipelines have their differences when it comes to approvals.

For release pipelines in order to create an approval flow you need to navigate in the stage and click the thunder strike. There you can locate the pre-deployment approvals and also gates that can be configured for that stage.

You can also define post-deployment approvals by clicking the person icon on the stage.

On the other hand in order to create approvals on build pipelines you will need to first create an environment. From environments you need to create a new blank environment

Then you need to navigate inside the environment and select approvals and checks

The last step would be to create a deployment job through YAML and point that environment. Every job which is created as deployment and has the environment configured will go through the approvals configured.

Lets see for example the below pipeline:

trigger: none

pool:
  vmImage: ubuntu-latest


stages:

- stage: stage1
  
  displayName: stage1
  jobs:
  - deployment: job1
    displayName: job1
    environment: appservice-west
    strategy:
      runOnce:
        deploy:
          steps:
          - task: PowerShell@2
            displayName: run powershell 1
            inputs:
              targetType: 'inline'
              script: |
                Write-Host "Hello from powershell 1"

- stage: stage2
  dependsOn: stage1
  displayName: stage2
  jobs:
  - deployment: job2
    displayName: job2
    environment: appservice-west
    strategy:
      runOnce:
        deploy:
          steps:
          - task: PowerShell@2
            displayName: run powershell 2
            inputs:
              targetType: 'inline'
              script: |
                Write-Host "Hello from powershell 2"

Before the execution of job1 and job2 an approval will be asked the way it is configured from the environment.

Trigger azure Devops pipeline from another repository

For security reasons you may want to store the pipelines to another repository than the one that the code is hosted. Lets say for example that you have your application code located on test-project/repository location but your pipelines are stored on the consoleapp1 repository. Also you want to have continuous integration and deployment for the repository on which the code is hosted, so when code is pushed to repository then the pipeline should trigger which is hosted on ConsoleApp1.

You can do that using the repositories resource of azure devops. You will need to define the repository and also configure trigger for this repository based on your strategy.

The final result would be the pipeline to run when code is commited on the code repository instead of the one that pipelines are hosted.

Using slots with appservice for Continuous delivery – Azure DevOps

Azure deployment slots allow your web apps to function in different instances called slots. Slots are different environments accessed through a publically available endpoint. One app instance is always assigned to the production slot, where you can toggle between multiple app instances on demand. This could contribute to have your application always available and deploy different versions without a downtime.

In this scenario we will examine an appservice setup called gservice that has a staging slot.

This staging slot will be used to deploy the code first, then do some health checks and finally swap this slot on production. In this article I will explain only the release procedure. If you want to learn how to build an appservice check the article attached below.

In the initial setup the staging environment and also the production one are both on v1. Lets say that code is pushed on the repository and now the version of the code is v2.

The first thing to do in the deployment would be to deploy the code on staging slot. This is an important step.

The code should be always deployed to staging slot.

Then after the code deployment some health tests will follow. If everything goes as expected we will need to swap the slots.

The swap should be performed always from staging to production slot.

After those two steps on your release pipeline you will have your code published on the production app service and the staging slot will retain the previous build for failover and backup reasons.