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.