How to deploy .NET APIs on Azure using GitHub actions

With Continuous Delivery (CD)You can deploy your code in a fast and stable way.

To deploy applications, you’ll need workflows to run and automate the process. In this way, you don’t have to perform repeated tasks and the whole process becomes less prone to errors.

In this article, we’ll learn how to implement CD pipelines using GitHub Actions. In particular, we will focus on the case of a .NET API application that will be deployed on Azure.

Create a .NET API project

Since the focus of this article is on the deployment part, we will not create complex APIs. Just a simple word of hello is enough.

For this, we will use the Dotnet Minimal API – a way to create APIs without scaffolding a lot of files and configurations.

Our API, BooksAPI, has one endpoint: /The root, simply returns “Hello World!”.

All our code is stored in Program file:

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.UseHttpsRedirection();

app.MapGet("https://www.code4it.dev/", () => "Hello World!");

app.Run();

Nothing fancy: run the app locally and navigate to root. you will see the Hello World message.

Finally, Put your code on GitHub: Initialize a repository and publish it to GitHub – this can be a public or private repository.

Create an app service in Azure

Now, to deploy an application, we need to define its target. We’re going to deploy it on Azure, so you need an Azure account before you go any further.

Open the Azure portalNavigate to the Application service segment, and create a new one.

Set it to your liking, then continue until you have it working.

After everything is done, you should have something like this:

Now the app is ready to use: Now we need to deploy our code here.

Create the GitHub Action YAML file for deploying .NET APIs in Azure

It’s time to create our continuous delivery pipeline.

Fortunately, GitHub already provides many templates for GitHub actions. We’ll need a specific one for our .NET APIs.

On GitHub, navigate to your repository, go to operations menu and select New workflow.

You’ll see a number of predefined actions that allow you to do Stuff with your pool. We are currently interested in the one called “Deploy a .NET Core App to an Azure Web App”:

Clicking “Set” will show a template. Read the instructions carefullyAs they will guide you to the correct configuration of the GitHub action.

In particular, you will need to update the environment variables detailed in this section:

env:
  AZURE_WEBAPP_NAME: your-app-name 
  AZURE_WEBAPP_PACKAGE_PATH: "." 
  DOTNET_VERSION: "5" 

clearly, AZURE_WEBAPP_NAME Must match the name you defined in Azure, while DOTNET_VERSION Must match the version you are using to create the dotnet APIs.

For my particular project, I replaced this section with

env:
  AZURE_WEBAPP_NAME: BooksAPI<myName> 
  AZURE_WEBAPP_PACKAGE_PATH: "." 
  DOTNET_VERSION: "6.0" 

🧧 DOTNET_VERSION Also requires the minor version of dotnet. definition 6 Will work now: You must specify 6.0. 🧧

Now you can save your YAML file to your repository: it will be saved under ./.github/workflows.

So, for reference, here’s the full YAML file I use to deploy my APIs:

name: Build and deploy ASP.Net Core app to an Azure Web App

env:
  AZURE_WEBAPP_NAME: BooksAPI<myName>
  AZURE_WEBAPP_PACKAGE_PATH: "."
  DOTNET_VERSION: "6.0"

on:
  push:
    branches: ["master"]
  workflow_dispatch:

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Set up .NET Core
        uses: actions/setup-dotnet@v2
        with:
          dotnet-version: ${{ env.DOTNET_VERSION }}

      - name: Set up dependency caching for faster builds
        uses: actions/cache@v3
        with:
          path: ~/.nuget/packages
          key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
          restore-keys: |
            ${{ runner.os }}-nuget-

      - name: Build with dotnet
        run: dotnet build --configuration Release

      - name: dotnet publish
        run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v3
        with:
          name: .net-app
          path: ${{env.DOTNET_ROOT}}/myapp

  deploy:
    permissions:
      contents: none
    runs-on: ubuntu-latest
    needs: build
    environment:
      name: "Development"
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v3
        with:
          name: .net-app

      - name: Deploy to Azure Web App
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v2
        with:
          app-name: ${{ env.AZURE_WEBAPP_NAME }}
          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
          package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

As you can see, we have 2 distinct steps: to build and slice.

In the to build In the step, we test our code, restore the NuGet dependencies, build the project, package it, and store the final result as an object.

In the slice In the step, we retrieve the newly created object and publish it to Azure.

Store the publishing profile as a GitHub Secret

As you can see in the instructions of the workflow file, you must

Create a secret in your repository named AZUREWEBAPPPUBLISH_PROFILE, paste the publish profile content as the secret value.

This Create a secret in your repository named AZUREWEBAPPto advertiseThe PROFILE_ statement was not clear to me: I thought you had to create this key inside your .NET project. Turns out you can create secrets associated with GitHub repositories (so it’s language agnostic).

A publication profile is a file that contains information and settings used to deploy applications in Azure. It is nothing but an XML file that lists the possible ways to deploy your application, such as FTP, Web Deploy, Zip Deploy and so on.

We need to get our publishing profile and keep it in GitHub secrets.

To retrieve the publishing profile, go to the Azure App Service page and click Get a profile to post to download the file.

Now, back to GitHub, head over to Settings > Security > Secrets > Actions.

Here you can create a new secret associated with your repository.

Create a new one, give it a go AZURE_WEBAPP_PUBLISH_PROFILEand paste the contents of the Publish profile file you just downloaded.

You will then see something like this:

Note that the secret name Must to be AzureWEBAPPto advertiseprofile_. This constraint is set because we access an ad profile using a key:

- name: Deploy to Azure Web App
    id: deploy-to-webapp
    uses: azure/webapps-deploy@v2
    with:
        app-name: ${{ env.AZURE_WEBAPP_NAME }}
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
        package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

In particular, pay attention to publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }} Smooth.

Obviously, the two names must match: nothing prevents you from changing the name of the secret in both the YAML file and the GitHub Secret page.

Final result

Time to see the final result.

Update the app code (I changed the Hello world message a bit), and push your changes to GitHub.

Under the Actions tab, you’ll see your CD pipeline running.

Once completed, you can access the root of your application and see the final result.

Additional readings

Automating repetitive tasks allows you to do more with fewer errors. In general, the more things you can automate, the better.

My blog relies heavily on automation: content scaffolding, idea tracking, and web publishing…

If you want to take a peek at what I do, here are my little secrets:

🔗 From Idea to Publishing, and Beyond: How I Built My Blogging Workflow with GitHub, PowerShell, and Azure | Code4IT

In this article we just built and deployed our app. We can do more: run tests and track code coverage. If you want to learn how you can do this using Azure DevOps, here it is:

🔗 Cobertura, YAML and Code Coverage Shield: How to View a Code Coverage Report in Azure DevOps | Code4IT

This article first appeared on Code4IT 🐧

finishing

I have to admit I struggled a lot with setting up the CD pipeline. I used the one offered by default in Visual Studio – but it didn’t work.

Using a template found on GitHub worked almost instantly – I just had to figure out what they meant The secrets of the reservoir.

Now we have everything in place. Since the workflow is stored in a text file within my repository, if I need to create and deploy a new API project I can simply do so by copying the file and fixing the references.

Nice and easy, right? 😉

Happy coding!

🐧