Azure Pipelines: Release to Azure App Service

This post is going to use the same Azure DevOps project used in last week’s Azure Repos and Azure Pipelines post which had a build pipeline and add a release pipeline that deploys to an Azure App Service.

This walkthrough is going to assume you have an Azure account already set up using the same email address as Azure DevOps. If you don’t have an Azure account one signup for an Azure Free Account.

Build Changes

The build set up in last week’s post proved that the code built, but it didn’t actually do anything with the results of that build. In order to use the results of the build, we need to publish theĀ resulting files. This will be needed later when setting up the release pipeline.

In order to get the results we are looking for a few steps mustĀ be added to our build.Ā  All the changes are being made in theĀ azure-pipelines.yml. The following is my full yamlĀ file with the new tasks.

pool:
  vmImage: 'Ubuntu 16.04'

variables:
  buildConfiguration: 'Release'

steps:
- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    projects: '**/EfSqlite.csproj'
    arguments: '--configuration $(BuildConfiguration)'
- task: DotNetCoreCLI@2
  displayName: Publish
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)'
- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact'
  inputs:
    PathtoPublish: '$(build.artifactstagingdirectory)'

As you can see in the above yamlĀ this build now has three different steps. The build (this is equivalent to what the post from last week was doing) and publish (this gets all the files in the right places) tasks are both handled using theĀ DotNetCoreCLI@2 task.Ā  Finally, theĀ PublishBuildArtifacts@1 takes the results of the publish and zips them to the artifact staging directory where they can be used in a release pipeline.

Create an Azure App Service

Feel free to skip this section if you have an existing App Service to use. To create a new App Service open the Azure PortalĀ and selectĀ App Services from the left navigation.

Next, click theĀ Add button.

On the next page, we are going to selectĀ Web App.

Now hit theĀ Create button.

The next page you will need to enter anĀ App name, select theĀ OS, andĀ Runtime Stack before hitting theĀ Create button. The OS and Runtime Stack should match the target of your application.

Create a Release Pipeline

On your project from the left navigation selectĀ Pipelines > Releases and then click theĀ New pipeline button. If you already have a release pipeline setup this page will look different.

The next page has a list of template you can select from. In this example, we will be selectingĀ Azure App Service deployment and then click theĀ Apply button.

 

 

Artifact Set Up

After clickingĀ Apply you will hit the pipeline overview page with to sets of information. The first is theĀ Artifacts which for us is going to be the results of the build pipeline we set up in last week’s post. Click theĀ Add an artifact box.

The Add an artifact dialog is where you will select where the release will get its build artifact form. We will be using the source type of build and selecting our existing build pipeline.

Once you select your build pipeline as theĀ SourceĀ a few more controls will show up. I took the defaults on all of them. Take note of the box highlighted in the screenshot as it will give you a warning if you build is missing artifacts. Click theĀ Add button to complete.

 

Stage Setup

 

Above we selected the Azure App Service template which is now in our pipeline as Stage 1. Notice the red exclamation, which means the stage has some issues that need to be addressed before it can be used. Click on the stage box to open it.

 

As you can see in the following screenshot the settings that are missing are highlighted in red on theĀ Deploy Azure App Service task.Ā  On Stage 1 click theĀ Unlink all button and confirm. Doing this means there is more setup on theĀ Deploy Azure App Service task, but this is the only way to use .NET Core 2.1 at the time of this writing. For some reason, the highest version available at the Stage level for Linux is .NET Core 2.0.

After clicking unlink all the options other than the name of the stage will be removed. Next, click onĀ Deploy Azure App Service task which handles the bulk to the work will place for this pipeline. There are a lot of setting on this task. Here is a screenshot of my setup and I will call out the important bits after.

First, select your Azure subscription. You may be required to Authorize your account so if you see anĀ Authorize button click it and go through the sign in steps for your Azure account.

Take special note ofĀ App type. In this sample, we are using Linux so it is important to selectĀ Linux App from the drop down instead of the just using Web App.

With your Azure subscription and App type selected theĀ App Service nameĀ drop-down should only let you select Linux based AppĀ  Services that exist on your subscription.

ForĀ Image Source,Ā I went with the Built-in Image, but it does have the option to enter use a container from a registry if the built-in doesn’t meet your needs.

For Package or folder, the default should work if you only have a single project. Since this, I have two projects I used the file browser (the … button) to select the specific zip file I want to deploy.

Runtime Stack needs to to be .NET Core 2.1 for this application.

Startup command needs to be set up to tell the .NET CLI to run the assembly that is the entry point for the application. In the example, this works out to beĀ dotnet EfSqlite.dll.

After all the settings have been entered hit theĀ Save button in the top right of the screen.

Execute Release Pipeline

Navigate back to Pipelines > Release and select the release you want to run. Then click theĀ Create a release button.

On the next page, all you have to do is select the Artifact you want to deploy and then click theĀ Create button.

Create will start the release process and send you back to the main release page. There will be a link at the top of the release page that you can click to see the status of the release.

The following is the results of my release after it has completed.

Wrapping Up

I took me more trial and error to get this setup going that I would have hoped, but once all the pieces are get up the results are awesome. At the very minimum, I recommend taking the time to at least set up a build that is triggered when code is checked into your repos. Having the feedback that a build is broken as soon as the code hits the repo versus finding out when you need a deliverable will do wonders for your peace of mind.


Also published on Medium.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.