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.
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.
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":
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 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.
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
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.