Posted on 1 Comment

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.

Posted on Leave a comment

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.

Posted on Leave a comment

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.

Posted on 1 Comment

Deploy an app service (web app) using Azure DevOps

In this article I will demonstrate how one can deploy app service code on Azure through Azure DevOps. App service is a hosting provider for your applications (web app) that can be created with multiple hosting options and application specific settings.

When creating an app service you can choose from many available options like different code frameworks or even container deployments.

For my demo I wanted to deploy an asp .net core web api using .net 6 version hosted on windows app service.

My repository structure is shown below. The app service that I want to deploy is the one located under Front folder.

The pipeline code can be found below:

trigger:
– none
pool:
vmImage: windows-latest
steps:
– task: VSBuild@1
displayName: Build appservice
inputs:
solution: '$(Build.SourcesDirectory)/Front/**\*.sln'
msbuildArgs: '/p:Configuration=Debug /p:Platform="Any CPU" /p:WebPublishMethod=FileSystem /p:publishUrl="$(Build.ArtifactStagingDirectory)/build" /p:DeployOnBuild=true'
clean: true
– task: ArchiveFiles@2
displayName: create archive for app service deployment
inputs:
rootFolderOrFile: '$(Build.ArtifactStagingDirectory)\build'
includeRootFolder: false
archiveType: 'zip'
archiveFile: '$(Build.StagingDirectory)/$(Build.BuildId).zip'
replaceExistingArchive: true
– task: AzureRmWebAppDeployment@4
displayName: deploy app service
inputs:
ConnectionType: 'AzureRM'
azureSubscription: 'ServiceConnectionName'
appType: 'webApp'
WebAppName: 'AppServiceName'
packageForLinux: '$(Build.StagingDirectory)/**/*.zip'

In more detail there are three necessary steps for the deployment.

The first task will build the .NET app using VSbuild task. The build will use as parameters the deployonBuild and the webpublishmethod as filesystem in order to specify the path on which the build output will be stored.

The second task will bundle this build output to a zip file and then the third task will upload this .zip file in the app service using a service connection with the subscription. The two parameters that should be changed are azureSubscription and WebAppName which should be the app service name.

When running the pipeline, a build folder will be created as shown in the below screenshot that will host the build output.

This output will be then zipped to a file that will be uploaded to the app service.