Playground for all things Azure cloud.
This solution takes advantage of Nuke.Build to define its CI pipeline. GitHub Action is uses to run the CI pipelines by publishing and deploying the artifacts to a Azure Web Service.
You can view the results at https://eilerpoulsen.com
Nuke.Build is a CI automation tool for .NET solutions. In this case, the application publishes the webapp artifacts and subsequently publishes the artifacts to Azure through zip deployment.
Nuke is set up to generate a workflow file that will run the CI process. This file is is generated at github/workflows/ci.yml, and is updated each time the command nuke is run within the root of the repository. This has the benefit of allowing you to test run your CI pipelines locally without having to commit and push your changes to test it on GitHub Action.
If you are running Windows, ensure that the end of line format is LN for all generated and updated files. Otherwise the CI workflow in GitHub Action will fail to run.
See the documentation on how to install and run the global tool: https://nuke.build/docs/introduction/#fast-track
In order to ensure that the artifacts can be deployed to Azure through the zip deployment method, the following secret variables need to be entered when running the workflow:
| Secret | Value |
|---|---|
| APP_SERVICE_NAME | SECRET |
| WEB_DEPLOY_USERNAME | SECRET |
| WEB_DEPLOY_PASSWORD | SECRET |
This can either be entered manually, or by defining the secret variables through the global nuke tool. See the following documentation on how to configure secrets: https://nuke.build/docs/global-tool/secrets/
The deployed application contains the commit sha value in its footer. This enables the administrator (in this case me) to be aware of what version of the application is deployed. The application's AppVersionInfo.cs service retrives this value at runtime from its assembly. See the Publish step in the build/Build.cs on how this is achieved.
GitHub Actions executes the github/workflows/ci.yml file generated by Nuke.Build as a workflow. The workflow is initiated whenever a new commit is pushed to the main branch.
In order to ensure that the artifacts can be deployed to Azure through the zip deployment method, the following secret variables need to be set up in the repository.
| Secret | Value |
|---|---|
| APP_SERVICE_NAME | SECRET |
| WEB_DEPLOY_USERNAME | SECRET |
| WEB_DEPLOY_PASSWORD | SECRET |
This can be achieved by navigating to the repository's settings page -> Security -> Secrets -> Actions. There you can create new repository secrets through the "New repository secret" button.
Updating the project's .NET version is a two stage process:
Open the solution in Visual Studio. Right click on the WebApp project, choose Properties from the context menu. Navigate to Build -> General. Pick the new Major Version in the Framework Version dropdown list. Save. Repeat the step for the build project.
Update nuget packages for each project to the latest versions.
If you encounter problems upgrading the GitVersion.Tools package for the build project then you will have to upgrade it manually through the terminal. Open a terminal in the root directory of the project, and enter the following command (adjust version number).
nuke :add-package GitVersion.Tool --version X.XX.X
You can find the latest version here on nuget, as well as the appropriate terminal command:
https://www.nuget.org/packages/GitVersion.Tool#nuke
Open the App Service running your service on the Azure Portal. Under Settings press on Configurations. From there, click on the General Settings. Pick the latest version in the Major Version dropdown list. Save your changes and restart the App Service.
The same steps are described here:
The process of adding Blazor support is based on the following article: https://mikaelkoskinen.net/post/combining-razor-blazor-pages-single-asp-net-core-3-application.
The project was initially created using Razor Pages template. Blazor support has been added manually. See #9.