Building a Software Survey using Blazor - Part 11 - Azure DevOps

I've decided to write a small survey site using Blazor. Part of this is an excuse to learn Blazor.

As I learn with Blazor I will blog about it as a series of articles.

This series of articles is not intended to be a training course for Blazor - rather my thought process as I go through learning to use the product.

All articles in this series:


I generally use Azure DevOps for my personal projects. Azure DevOps is described as:

"Azure DevOps provides developer services to support teams to plan work, collaborate on code development, and build and deploy applications." Source

And for the purposed of Continious Integration, Delivery and Deployment, I use the Pipelines service of Azure DevOps.

What's in a name?

Personally I'd rather that Microsoft marketing hadn't decided to use the name "DevOps" for the collected services.

I can understand why they chose it - but it only adds to the confusion over what DevOps is.

DevOps is not a product. DevOps is not a job role. DevOps is much wider than that.

I love the definition of DevOps from Donovan Brown (of Microsoft):

"DevOps is the union of people, process, and products to enable continuous delivery of value to our end users." Source

I actually preferred the services pervious name "Visual Studio Team Services" or "VSTS" - but I can also see that as being rather limiting.

Pipelines

The Pipelines service of Azure DevOps provides build and deployment services similar to Circle CI, TeamCity, Jenkins, Octopus Deploy, etc.

It often seems to be overlooked as a CI/ CD tool - but is actually very good.

For this project, I defined 3 "pipelines":

The Build, Test and Deploy pipeline

As the name suggests, on commit of any change to Github, the pipeline will build, test and deploy the Blazor Server app to an Azure App Service.

The pipelines will:

This is all fairly standard stuff - the YAML for the pipeline can be found here on GitHub.

The Production Smoke Test pipeline

The Production Smoke Test was scheduled to run every hour while the survey was open (the month of September).

The Production Smoke Test would use the End to End tests Published by the Buid, Test and Deploy pipeline to run them against the production site.

I was effectively using the pipeline to run a synthetic transaction through the production app on a regular basis - using the standard pipeline notification capability to alert if the test failed.

The pipeline will:

The YAML for this pipeline can be found here on GitHub.

The E2E Test pipeline

This is the most complicated of the pipelines - and the least used.

I wanted a full end to end build of the environment, deploy the app, test it and destroy the environment pipeline - and this is it.

I generally only run this manually - but in a client environment, I would probably look to incorporate into the Build, Test and Deploy.

Because this is standing up Azure services (Cosmos DB and SignalR), this test does take longer to run (just over 20 minutes).

The pipeline will:

The YAML for this pipeline can be found here on GitHub

Key takeaway for Blazor Server

In short, when it comes to CI/ CD - there isn't really anything special we need to do for Blazor Server. It’s just like deploying any ASP.Net application.

Yes we may need different services to support it (mainly the SignalR), but that is just part of the ARM setup (assuming you deploy from scratch).

In the next article, I'll talk about pulling all of this together for the final solution.

About the author:

Mark Taylor is an experience IT Consultant passionate about helping his clients get better ROI from their Software Development.

He has over 20 years Software Development experience - over 15 of those leading teams. He has experience in a wide variety of technologies and holds certification in Microsoft Development and Scrum.

He operates through Red Folder Consultancy Ltd.