Branch and release strategies using Azure DevOps when deploy to Episerver DXP environments.
This blog post is the second in a series
- Part 1: Introduction
- Part 2: Branch and release strategies
- Part 3: A closer look at the Epinova DXP deployment extension for Azure DevOps
- Part 4: How to set up a CI/CD pipeline (Prerequisites and Release candidate strategy)
- Part 5: How to set up a CI/CD pipeline (Classic Strategy, Reset and Hotfix pipelines)
Episerver released its deployment API for Episerver DXP late last year as a Beta. At Epinova, we have tried to standardize how we use this together with Azure DevOps that’s our CI/CD tool for new projects. In the second part of this blog series we will go through some basics and describe two branch and release strategies that we will use when setting up the CI/CD in Azure DevOps in the later blog posts in this series.
At Epinova, we try to use the GitFlow branching strategy in as many projects as possible. If you are not familiar with GitFlow, I suggest that you read the following tutorial: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
At a high-level summary, we want developers to create “feature” branches from the “developer” branch for each task that they are working on. When they are done with the task, they create a pull-request so that other developers can review the code. We do this to learn from each other and increase quality and it’s also a great way of knowledge sharing between the developers.
When the “feature” branch is approved and merged into the developer branch, we want Azure DevOps to automatically build and deploy the developer branch to the Episerver DXP Integration environment. We look at the Integration environment as our internal test website for new functionality.
Once you are ready to release something to do final approval testing you create a “release candidate” branch which should be created from the “developer” branch. When the “release candidate” branch is created, we want Azure DevOps to build and release it to the Preproduction environment so that final testing can be made on a more stable codebase. If everything is approved and working as expected, the code for Preproduction can then be released to the Production environment. We look at the Preproduction environment as the customer acceptance test environment. Don´t forget to merge your release branch to both master and developer branch after approved deploy to production.
The above is a simplified description, but I think it is nice to describe what kind of context we try to achieve here.
Now when we have looked on the branch strategy, we need to decide which release strategy to use. We have targeted 2 strategies that we like. The one we recommend, because we think it match the GitFlow branch strategy best, is the “Release candidate strategy”. We also have the “Classic strategy” that many use today – and that also mimics the traditional UI based Episerver DXP deployment.
“Release candidate strategy” (recommended)
This strategy deploys the developer branch to the Integration environment. Then either a release candidate or the master branch is deployed to Preproduction, and after final approval it’s also deployed to the Production environment.
We see the Integration environment as a testing environment to be able to test new functionality or bug fixes internally within the team while the Preproduction environment is used as a customer/project manager/product owner acceptance test environment.
Developer branch => Integration
When a developer merges code into the developer branch this triggers an CI/CD pipeline that builds the package and deploys it to the Integration environment. The Epinova DXP deployment extension supports both WebPackage and NuGet package scenarios (we will look more into this later in this series).
Release candidate/master branch => Preproduction => Production
When a developer creates a release branch it triggers a CI/CD pipeline that builds the package and deploys it to the Preproduction environment. When the Preproduction environment is approved the code can then be deployed into the Production environment.
Master branch => Integration => Preproduction => Production
When a developer merges code into the master branch it triggers a CI/CD pipeline that builds the package and deploys it to the Integration environment. The Epinova DXP deployment extension supports both WebPackage and NuGet package scenarios.
When the Integration environment has been approved the pipeline can continue the deployment to the Preproduction environment approved, the pipeline can finally deploy to the Production environment.
Hotfix - pipeline
The hotfix release is used to be able to deploy a fix straight out to the Production environment. This release should, of course, only be used when there is a serious bug in the Production environment that needs a fix as soon as possible. This type of release is very useful if you have a critical error that needs to be fixed immediately and where time to release is more important than testing the new release.
In this post we covered branching and release strategies. In the next post web can start taking a closer look of how the Epinova DXP Deployment extension works.
For the latest documentation and guides please visit the repo on GitHub. Where all code, documentation and YAML files etc. exist.