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.
Earlier articles in this series:
- Part 1 - State
- Part 2 - Better State
- Part 3 - Components
- Part 4 - Render Mode
- Part 5 - Client IP
- Part 6 - Azure Cosmos DB
- Part 7 - Azure SignalR Service
- Part 8 - bUnit
- Part 9 - End to End Tests
- Part 10 - Bicep
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":
- Build, Test and Deploy
- Production Smoke Test
- E2E Test
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:
- Restore nuget packages
- Build the Software Survey solution
- Run the Unit Tests (the SoftwareSurvey.UnitTests and SoftwareSurvey.Models.UnitTests projects)
- Publish the Software Survey app
- Deploy to the Software Survey app to Azure App Services
- Copy and Publish the End to End Tests (the SoftwareSurvey.E2ETests project)
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:
- Download the E2E Tests (from the Build, Test and Deploy pipeline) to the agent
- Configure the Chrome Web Driver (needed for the End to End tests)
- Run the test
- Publish the final screen of the test - this allowed me to review what the app looked like if the test failed
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:
- Create the Azure environment - using ARM template generated by Bicep that I talked about in part 10
- Get the output values from the ARM template - these are used later when running the E2E tests
- Download the app (from Build, Test and Deploy pipeline)
- Deploy the app new environment
- Download the E2E Tests (from the Build, Test and Deploy pipeline) to the agent
- Configure the Chrome Web Driver (needed for the End to End tests)
- Run the test
- Publish the final screen of the test
- Remove the Azure environment
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.
Top comments (0)