Every single one of our websites is stored in a DevOps repository, but with the introduction of Umbraco Cloud, deployments have become more challenging than just building and releasing to either a virtual machine or an App Service. Using traditional DevOps pipelines allows us to easily test project iterations internally before releasing to the cloud (dev/stage/prod). This approach also resolves issues that may arise when we push changes to the cloud, but then Umbraco pushes updates as well. This could result in package differences, requiring us to update our local repositories to keep them up to date with the cloud. This can be painful to maintain on larger change request projects.
This article will demonstrate how we achieved full CI (Continuous Integration) and CD (Continuous Deployment) integration between our Azure DevOps and Umbraco Cloud environments.
Initially, our process looked like this:
- Code is pushed to the DevOps repository (PR).
- The build pipeline is triggered.
- The build creates an artifact and executes a PowerShell script stored in the repository.
- The PowerShell script pushes the artifact to the Umbraco Cloud Development environment.
While this approach works correctly,it is for CI only and requires us to change the PowerShell script slightly for each Umbraco Cloud project due to differences in the repository URL, credentials, artifact name, and so on.
You can view the PowerShell script here. In brief, the script checks out the cloud repository and retrieves our artifact. It then compares the major DLL versions between the local and cloud environments to ensure that we don't accidentally push older packages. Worth to note Umbraco.Cloud.Identity.Cms.dll is so not available in nuget package manager.
Finally, it pushes our artifact to the Umbraco Cloud environment (all of our commits are also visible in the cloud repository).
To get continues delivery approach with DevOps I came with developing simple VSTS extensions task that can be installed in DevOps release pipeline and will require few fields to be filled, which are then passed to mentioned powershell script.
Password is taken from release variable.
CI pipeline is rather casual .NET build pipeline and looks like below:
There are couple of improvements to this task that could be done, but it does work as expected and matches our requirements. Github repo have some details on how to install and update it to match your needs or you can simply install it from marketplace.