Auto-deploy React Apps / .NET APIs using .NET stack, codified pipelines and Azure DevOps

6 min readJul 10, 2021

A how-to guide to build your CI/CD pipeline for Asp.NET 5.0 APIs or React Apps

Why do I need a Codified Pipeline?

The automated deployment pipeline is the bridge between the beautiful apps we develop, and the infrastructure we use to host those apps.

I know that, but why codified? The larger our software ecosystem gets, the harder it gets to apply consistency across the who ecosystem. When the pipelines are not codified, it means people can use user interfaces and make changes without code review and governance.

Tiny mistakes, which could be avoided by a simple review, cause big problems and it costs a fortune to fix their side effects.

So not only we need to have our pipelines automated, they also need to be codified, to help us with compliance and efficiency at scale. And that’s the focus of this post; How to create an ecosystem of assets that function automatically and safely at scale.

For the purpose of this post, I use a React app being deployed on .Net stack using Asp.NET, and deployed to Azure using Azure DevOps.

By the way, this topic belongs to the series to set up an Asp.NET API for production use.

1. Codified Pipeline

As I am relying on Azure DevOps for the deployment of my assets, I have chosen a yaml based pipeline to build them in the first place, which helps me to keep the entire pipeline build pipeline defined in code.

1.1 Notes

Location: azure-pipelines.yaml file should be located at the root of your git repository, for Azure DevOps to pick it up.
Variables: I generally define variables in my pipeline, so the rest of the file is not filled with changing values
5 Steps: My pipeline has 5 steps, which are executed sequentially, and at the end the artefacts are deployed to Azure Artifactory
NuGetAuthenticate: This step took a bit of my time, as my pipeline kept failing with authentication errors, and the reason was I didn’t have this step.

Once you push the changes to your Git repository, you need to create a new pipeline for it, which involves picking the yaml file as the definition of your pipeline. It is very simply, and you just need to follow the steps.

After I get a green pipeline, it means that the build output is being packaged and pushed to Artifactory. The next step is to pick that up and use a release pipeline to deploy that to Azure Web App.

By looking at the Artifactory, I can see the libraries and packages are being pushed, which confirms they are ready to be picked up for deployment by a release pipeline.

2. Release Pipeline

The next step in our process is to configure the release pipeline, to deploy our apps into Azure App Service.

However before I get into the release pipeline, let me show you my configurations for the WebApps:

Stack: As you can see, I have chosen .NET 5.0 as the stack
Http Version: I have selected Http2 as my http version for its superior performance
Always On: To prevent the App/API from going idle and avoid the warm-up performance cost

Once this is done, I am ready to create the Release pipeline. Below is a high level overview of such pipeline.

The pipeline is attached to 1 artefact, and has two stages which I explain shortly.

2.1 Add Artefact

You should now select which build pipeline it is related to, and which artefact you are going to grab for the deployment.

2.2 Continuous Deployment Trigger

You also need to enable the Continuous Deploy Trigger, so anytime something is pushed to master, you will grab it and deploy it.

2.3 Stages

I have two stages for my App/API deployment:

Deploy the App/API to Azure App Service
Apply necessary configurations through Azure CLI

2.3.1 Deploy

Deploy is pretty straight forward, choose your subscription, choose the app name, and set deployment method (in Additional Deployment Options) to WebDeploy. You can also take your app offline while the deployment is being done, if you like.

Note
Configuration, plumbing and troubleshooting your software foundation take a considerable amount of time in your product development. Consider using Pellerex which is a complete foundation for your enterprise software products, providing source-included Identity and Payment functions across UI (React), API (.NET), Pipeline (Azure DevOps) and Infrastructure (Kubernetes).

2.3.2 Azure CLI to Configure Your App

There are a bunch of settings that you need to apply once for each application. However to make sure you don’t have to do them again, in case you wanted to re-host them elsewhere in another App Service for example, you better do them in script.

What this script does, is to create an environment variable for your target environment (production). This is the same value that would be picked up whenever you use Environment.GetEnvironmentVariable(“ASPNETCORE_ENVIRONMENT”) in your .NET application. Other settings I have included in this script allows your app/api to read secrets/certificates from the vault, if it needs to.

Once you run your pipeline, you can see these setting applied in the Configuration Section of your App/API.

Pellerex Foundation: For Your Next Enterprise Software

How are you building your current software today? Build everything from scratch or use a foundation to save on development time, budget and resources? For an enterprise software MVP, which might take 8–12 months with a small team, you might indeed spend 6 months on your foundation. Things like Identity, Payment, Infrastructure, DevOps, etc. they all take time, while contributing not much to your actual product. These features are needed, but they are not your differentiators.

Pellerex does just that. It provides a foundation that save you a lot development time and effort at a fraction of the cost. It gives you source-included Identity, Payment, Infrastructure, and DevOps to build Web, Api and Mobile apps all-integrated and ready-to-go on day 1.

Check out Pellerex and talk to our team today to start building your next enterprise software fast.