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.

Posted on Leave a comment

Deployment strategy with environments – Azure DevOps

Its a common thing for DevOps engineers to define some agent pools that hold agents and organize their deployments through those pools. I have worked with this approach as well by defining Uat and Prod pools that are used from build and release pipelines.

In this article I will explain how to use the environment resources that are located under Pipelines section.

Environments are a collection of resources on Azure DevOps through which you can define your deployment strategy, approvals and conditions. An environment could be a custom one, or a predefined like a virtual machine or Kubernetes cluster.

It is important to understand the difference between an agent pool and an environment as you have the option to run a deployment job with an environment that has no resources.

This is possible because environments are the scope at which you define pre-deployment checks (approvals, gates, etc). Deploying to resources defined in an environment is an option, not a requirement.

As an example, if you have a serverless Azure web app, you use an environment to define the approvals and gates required to deploy to that environment, but then actual deployment activities occur on an agent from an agent pool because an Azure Web App doesn’t have any physical machines to deploy to.

Lets now examine how you could create your own environments to define your strategies. From environments select add new environment

In my case I will select windows virtual machines as I will use common windows servers as deployment machines.

Then the registration script will be provided to register your machine as an Azure DevOps agent so that jobs can run on those environments. If you use empty environments just for approvals you will not have to run scripts or install an azure devops agent.

Azure DevOps will automatically create a Personal Access Token for the agent registration. You can either create a new one, or use the created one. Keep in mind that the life timespan of this token will be three hours. If you want to have the agent alive, you can extend the expiration time of the token.

You will have to save the script as .ps1 on your target machine and run it as administrator.

$ErrorActionPreference="Stop";If(-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent() ).IsInRole( [Security.Principal.WindowsBuiltInRole] "Administrator")){ throw "Run command in an administrator PowerShell prompt"};If($PSVersionTable.PSVersion -lt (New-Object System.Version("3.0"))){ throw "The minimum version of Windows PowerShell that is required by the script (3.0) does not match the currently running version of Windows PowerShell." };If(-NOT (Test-Path $env:SystemDrive\'azagent')){mkdir $env:SystemDrive\'azagent'}; cd $env:SystemDrive\'azagent'; for($i=1; $i -lt 100; $i++).....

During the configuration I proceeded with the default values. (just press enter)

When you finish with the configuration of your agents you will have the recources listed under your environment. In my case those are two virtual machines, test-qa and test-dev

Lets now define a deployment strategy. You can choose between the rolling, runOnce, canary deployments. Each of them are explained on the documentation article that I have included on the bottom of the page.

  • runOnce is the simplest deployment strategy and most steps are executed once. (preDeploy, deploy, routeTraffic)
  • A rolling deployment replaces instances of the previous version of an application with instances of the new version of the application on a fixed set of virtual machines (rolling set) in each iteration
  • Canary deployment strategy is an advanced deployment strategy that helps mitigate the risk involved in rolling out new versions of applications. By using this strategy, you can roll out the changes to a small subset of servers first. As you gain more confidence in the new version, you can release it to more servers in your infrastructure and route more traffic to it.

In the below pipeline I added a rolling strategy. The max parallel execution percentage is 50% this means that the deployment will be executed first on my dev server and then on my qa server after all tasks of the dev are finished. The deployment test task will create a file and paste some text on it.

trigger:
- none

pool:
  vmImage: ubuntu-latest

stages:
- stage: deployment
  displayName: Deploy on Environment
  jobs:
  - deployment: VMDeploy
    displayName: Deploy to VM
    environment: 
      name: azure-test-dev
      resourceType: VirtualMachine
    strategy:
      rolling:
        maxParallel: 50%
        preDeploy:
          steps:
          - script: echo running pre deployment steps
        deploy:
          steps:
            - script: echo running rolling strategy on windows servers > C:\output

Strategy sequence:

  • Dev server -> predeploy step
  • Dev server -> deploy step

When the deployment for the dev server is completed then the qa server deployment will start.

  • QA server -> predeploy step
  • QA server -> deploy step

You can also define approvals and checks for your stages on the deployments. For example you could define a stage to be deployed only during working hours or from a specific branch.

Lastly you should give access to the environment from the pipeline that you created.

File created from the pipeline

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops

https://stackoverflow.com/questions/68912591/trying-to-understand-deployment-jobs-in-azure-pipelines