ASP.NET Core Unified Build and Release

In this post, I will be showing us how to setup an ASP.NET Core application to use Azure DevOps Unified Build and Release using the YAML spec.

First step is to have my existing ASP.NET Core application. You can do a quick setup of this with

dotnet new webapp in your choice directory or you can use any of your existing ASP.NET Core web applications.

This will generate a boilerplate template.

Next step is to put your code in source control.

Now it’s time to rub a ‘lil devops on it.

Just some housecleaning, you should have signed up for Azure DevOps at dev.azure.com. House clean, let’s go.

  • Login to Azure DevOps (dev.azure.com)
  • Navigate to Pipelines
  • Create a new Pipeline
  • Select your repository source – in my case, I am using Azure Repos Git YAML
  • Select your ASP.NET Core Project
  • Use Starter pipeline

Some code will be YAML code will be pre-populated for you. Feel free to delete them.

I will be deploying the application to Azure. I am not covering ARM Templates in this post, so I have gone ahead to create an Azure Web App (Linux – Runtime – ASP.NET Core 2.2).

Let’s now go YAML by YAML

Please note – INDENTING is a thing in YAML, so take good note. You can get the full code in my GitHub Repo.

First is to set your build trigger, what this means is the branch to watch for updates to initiate the pipeline. I’m setting this to master.

trigger:
- master

Stages exist to simplify build and release management. So, I can have my build and release stages as I have in this sample.

First is to build my project – for this I set the build stage, give it a display name (for cleanliness and sanity sake)

stages:
  - stage: build
    displayName: 'master-branch-build'

Next step is to set our job.

#build jobs
    jobs: 
      - job: build
        pool:
          vmImage: 'ubuntu-latest'

        variables:
          buildConfiguration: 'Release'

This uses an Ubuntu machine to build our application in Release Configuration. Now we go ahead to define our build and artifacts drop set of tasks

steps:
        - task: DotNetCoreCLI@2
          inputs:
            command: 'restore'
            projects: '**/*.csproj'
            feedsToUse: 'select'
        - task: DotNetCoreCLI@2
          inputs:
            command: 'build'
            projects: '**/*.csproj'
            arguments: '--configuration $(BuildConfiguration)'
        - task: DotNetCoreCLI@2
          inputs:
            command: 'publish'
            publishWebProjects: true
            arguments: '--configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)'
        - task: PublishBuildArtifacts@1
          inputs:
            PathtoPublish: '$(build.artifactstagingdirectory)'
            ArtifactName: 'drop'
            publishLocation: 'Container'

What the above YAML snippet does is to first do a dotnet restore on all projects it can find then build in release configuration. After building, it publishes our application and dependencies to the artifacts staging directory in Azure DevOps. Finally, it copies those published files into the drop folder to hand over to our release stage.

Now let’s release.

- stage: release
    displayName: 'deployment-release'
#release job
    jobs:
      - job: release
        pool:
              vmImage: 'ubuntu-latest'
        steps:
        - task: DownloadBuildArtifacts@0
          inputs:
            buildType: 'current'
            downloadType: 'specific'
            itemPattern: '**/*.zip'
            downloadPath: '$(System.ArtifactsDirectory)'


        - task: AzureRmWebAppDeployment@4
          inputs:
            ConnectionType: 'AzureRM'
            azureSubscription: '<subscriptionNameHere>(<subscriptionIdHere>)'
            appType: 'webApp'
            WebAppName: 'appNameHere'
            packageForLinux: '$(System.ArtifactsDirectory)/**/*.zip'

What happened in this stage?

  1. We set the release job to still run on Ubuntu.
  2. We downloaded the artifacts from the previous stage.
  3. We published our downloaded artifacts to our Azure Web Application.

We go ahead to save our YAML file into the master branch. A build is then automatically triggered. We wait a couple of seconds or minutes and our application goes live.

The screenshot below show me using this process for building and releasing making a total of 3 stages.

What I painted in this blog post is a simple scenario, you may have more complex scenario with more than just 2 stages, maybe you have a dev, staging and production environment, the same principles apply.

You can find the YAML code at this link.