GitHub Actions + Azure: Continuous deployment of ASP.NET Core with DotVVM applications

In the world of software development, words such as continuous implementation are always present. In this case, continuous deployment is a strategy for software versions, so that any code commit that passes the testing phase automatically is released in a production environment, deploying changes that are visible to users of the software in question.

This is a small variation of continuous delivery because if you had to perform a manual deployment before, here in (CD) simply for each merge to the master branch is proceeded to perform a deployment automatically, the process remains as follows:

• Change Control (Source Control)
• Build and Tests
• Staging (Staging)
• Deploy to Production: Latest version running on the main website

Taking these considerations into account, with continuous deployment, the entire process from code commit to production is automated. The trigger between the development and delivery phases is automatic, so code changes are pushed live once they receive validation and pass all tests. This means that users receive improvements as soon as they are available.

In this tutorial article, we'll learn step-by-step the process of continuously deploying a web application developed with DotVVM through ASP.NET Core to publish it automatically and continuously to an Azure App Service resource, using GitHub Actions.

In relation to GitHub Actions, this is a functionality that allows us to create workflows that can be used to compile, test and deploy code, giving the possibility to create integration flows and continuous deployment within the GitHub repository itself as we will see later.

Activities:

To carry out continuous deployment activities, we have three important parts within this process:

• Part 1: Associate the project in question from Visual Studio 2019 with a repository on GitHub.
• Part 2: Create an App Service resource in Azure.
• Part 3: Configure deployment actions to Azure in the GitHub repository.

Required Resources:

To follow this article step by step, you need to have these tools:

• .NET Core SDK.
• Visual Studio 2019.
• Workload: Web Development and ASP.NET, for Visual Studio 2019.
• The DotVVM extension for Visual Studio 2019.
• A GitHub account.
• An Azure subscription.
• If the project is associated with a database, it must be hosted in the cloud.

The solution environment

Projects for application development with ASP.NET Core and DotVVM are based on the Model, View, View model pattern; for communication between HTML (web pages) and C# (source code). The purpose of these parts are as follows:

• Model. — is responsible for all application data and related business logic.
• The view. — Representations for the end-user of the application model. The view is responsible for displaying the data to the user and allowing manipulation of application data.
• Model-View or View-Model. — one or more per view; the model-view is responsible for implementing view behavior to respond to user actions and for easily exposing model data.

In this case, there are three projects for this purpose:

• DAL (Data Access Layer): to manage database connection and access.
• BL (Business Layer): for the handling of services and application domain logic.
• APP - Application Presentation Layer. This section is where we have Views and Viewmodels for designing web pages with DotVVM.

The solution in Visual Studio 2019 looks like this:

Want to know the steps to create a DotVVM app? To do this you can review this article: Steps to create an MVVM application (Model-View-ViewModel) with DotVVM and ASP.NET Core.

Part 1: Associate the project from Visual Studio 2019 with a repository on GitHub

The first thing to do is to verify that we have the GitHub extension installed for Visual Studio 2019. To do this we can go to the options menu in the Extensions section and select the Manage Extensions option. In this box, we can perform the verification.

In case you do not have the GitHub extension for Visual Studio 2019, the installer can be found at the following address: visualstudio.github.com/. To add the extension, Visual Studio must be closed as they are changes to the Microsoft IDE that are made during installation.

Now, we proceed to associate with the solution that contains the three projects (.APP, .BL and . DAL) to a repository on GitHub, to do this, right-click on the Visual Studio solution and select Add Solution to Source Control:

Later we went to the Team Explorer view and connected our GitHub account to Visual Studio in the Connect option.

Then we go to the Team Explorer option: Synchronization: select Publish to GitHub and continue with the instructions presented for creating a new repository.

A short time later, our project will be associated with the repository we just created. We can check this directly from GitHub:

Note: Whenever we need to save our changes, we can save them from the Changes section of Team Explorer:

And in the Sync section we need to confirm the output changes:

With these first steps, our application with DotVVM and ASP.NET Core in Visual Studio 2019 is already associated with a particular GitHub repository.

Part 2: Create an App Service resource in Azure

To create an App Service-type resource in Azure, we can go to the portal: portal.azure.com/ and then search for the service in the left pane of Azure where the most commonly used Azure resources are located or in the search section. In either scenario, we proceed to create the resource and to the end, we will have something like this:

In which, we will need to specify the name of the Web App, the runtime environment, which in this case is .NET Core and its latest version 3.1 (August 2020). We also need to specify the operating system on which the application will be deployed.

The creation process will take a few seconds.

Then we should go to the resource in the general section and in the options menu in the Get Post Profile section, click to download the corresponding publishing file. This file will allow us to set action on GitHub for continuous deployment, as we'll see in Part 3.

Part 3: GitHub Actions for continuous deployment of applications in Azure

In the GitHub environment, a workflow is an automated process that is defined in a GitHub repository. This process tells GitHub how to create and deploy a function app project on GitHub.

With these considerations in mind, GitHub Actions enables us to create custom software lifecycle workflows directly in a GitHub repository. In this sense, actions allow us to create, test, and deploy our code directly from GitHub.

In our case study, GitHub actions allow us to define a workflow to automatically create and deploy the project developed with ASP.NET Core and DotVVM in the Azure function application.

To create this workflow we will perform these activities:

• A. GitHub Secret Settings
• B. Set up a workflow
• C. Continuous implementation in action

To get started, we'll head to the GitHub repository created from Visual Studio 2019 in Part 1. With this repository, we will perform each of the activities initially established.

A. Setting up GitHub's secret

Within the repository in question, in the options menus we will go to the path Settings > Secrets > New secret.

In this section we will specify the name of the secret, in this case, it will be SCM_CREDENTIALS, and the value, which corresponds to the content of the publish file downloaded from the App Service resource in Azure, set out in Part 2. The fields will look like this:

Finally, select in Add secret.

B. Set up a workflow

Now what we'll do is configure the workflow that will allow us to set the functionality for continuous deployment to Azure. To do this, within the repository, we need to go to the Actions section and select in set up a workflow yourself.

Note: in this Actions section we can also find workflows already established for other types of operations, for example:

When attempting to create a workflow on our part, a YAML (.yml) file will define this flow in the repository path /.github/workflows/. This definition includes the various steps and parameters that make up the workflow.

That said, this section is where we'll write the source code for the workflow. The final code is as follows:

# Docs for the Azure Web Apps Deploy action: https://github.com/Azure/webapps-deploy
# More GitHub Actions for Azure: https://github.com/Azure/actions

name: Build and deploy ASP.NET Core with DotVVM app to Azure

on:
  push:
    branches:
      - master

jobs:
  build-and-deploy:
    runs-on: windows-latest

    steps:
    - uses: actions/checkout@master

    - name: Set up .NET Core
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: '3.1'

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

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

    - name: Deploy to Azure Web App
      uses: azure/webapps-deploy@v1
      with:
        app-name: '<APP_NAME>'
        slot-name: 'production'
        publish-profile: ${{ secrets. SCM_CREDENTIALS }}
        package: ${{env.DOTNET_ROOT}}/myapp 

Next, let's look at the most important parts of this code.

In the name section we have the definition of the action name. We can have multiple actions in the same file and multiple files in the folder .github/workflows.

The action trigger is defined in the on section, which can be any event that triggers workflows, where the most common ones are push and pull_request, but there are many other triggers. In this case, that will be the action that will indicate that a new continuous deployment process should be initiated.

Then in jobs, we have the definition of jobs. The name of this group is called build-and-deploy. Continuing with this sequence, Github's actions define three execution environments for its jobs: windows-latest, ubuntu-latest, and macos-latest which are defined in the runs-on node and run virtual machines for the execution of subsequent statements. In this case, it has been set to windows-latest. The steps are then defined in the steps section:

• As a first step, we find the definition of the type of workflow, in this case, use is used, which allows us to integrate into our flow with actions defined by third parties.

• Then the version ASP.NET Core is defined, in this case, it is necessary to specify in this section the version of our ASP.NET Core project with DotVVM. The version in this example is 3.1.

• The project is then built in the Build with dotnet step.

• Then the necessary files are prepared for deployment with dotnet publish.

• Finally, the deployment of these files to Azure takes place. In this case, it is necessary to indicate the name of the App Service resource created in Azure in the attribute app-name and in publish-profile the name of the secret created in the GitHub repository is indicated, for this case, the name set in part B was SCM_CREDENTIALS.

Then we save the YAML file and the workflow will be ready to perform continuous deployment whenever there is a change in the repository.

C. Continuous implementation in action

When we make any changes within the repository or from Visual Studio 2019, the workflow will run. From the Actions section in the GitHub repository we can see how this process is done step by step, according to the names and steps set in the YAML file.

The end result of this implementation is as follows:

What's next?

With this article, we have learned step by step how to continuously deploy web applications with ASP.NET Core and DotVVM through GitHub Actions.

The sample project source code is available in the following repository: DotVVM Sample CRUD.

Here are some additional resources that might be of interest to you to continue to gain new knowledge in this area:

• Free and open course on YouTube (Spanish): ASP.NET Core and DotVVM Fundamentals.
• DotVVM and ASP.NET Core: Implementing CRUD Operations.
• Working with web services through ASP.NET Core and DotVVM.

Thank you:

If you have any concerns or need help in something particular, it will be a pleasure to be able to collaborate.

See you on Twitter!! :)