Implementing Simple and Effective Branching and Deployment Strategy with Azure DevOps

In the previous post, we have discussed, a simple and effective branching and deployment strategy as a concept. Let’s now have a look at key implementation considerations of the proposed strategy with Azure Git repos and Azure Pipelines.
Let’s have a look at pictorial representation of the proposed strategy first.

In the, previous post we identified each of the above branches, builds and environments and their usage in theory. Let’s see the implementation concerns of them now one by one.
Once a repo is created you will get a master branch in Azure git repos. The you can submit initial code structure to the master branch and create a branch with the targeted version say 0.0.1. You should use version/<version number> format so that all version branches would go into a folder version. When work on next version starts you can create another version/<version number> branch.

Then you can implement one build for each relevant microservice (if you are implementing microservices, or else a build for your project) in your Azure pipeline which builds, execute unit tests and then package and pushes artifacts to Azure DevOps Artifacts. The build should be set to trigger for master branch any feature branch or version branch as shown below. If microservices build then can use the path filters to build only when files changed in a given microservice. For this you have two options, using a git repo for each microservice or use folders within same repo. When fodders within a repo is used, path filters help to filter the triggering of builds to relevant folder content changes.

Then the build can be set to protect the required version branch using branch policies. Path filters can be applied in the build policy so that it validates incoming changes to given paths. Excluding paths helps to build only the incoming PRs for a given path.

Release pipelines can be setup to allow triggering for the version branches targeting the first environment as Automated Test environment. You can set the release paths so that above mentioned release pipeline flow can be achieved.

In above TEST – V environment allows a release from version branch to be deployed automatically to Test environment (where automated tests are executed against) once a new build from the version branch is available. This is achieved by setting the build to trigger a release automatically when a new build is available from version/* branch.

Then a filter is applied in TEST – V environment to make sure it gets deployed only with the code from version/* branch.

Then the QA team will accept it to QA environment on demand. This is handled though pre deployment approval and setting to deploy after Test environment.

Pull request triggers are enabled in the release pipeline allowing to get a release triggered based on an incoming Pull Request validation build success.

The TEST – PR environment is the same Test environment where the automated tests are executed targeting the deployment in this environment. It is set to trigger for pull request build availability and branches are filtered to make sure none of version/* or feature/* build will not be deployed to TEST – PR environment.

Again, QA team will only accept a deployment from pull request validation to QA environment on demand and based on if it succeeds in Test environment. The PR cannot be deployed beyond the QA environment due to the way the pipeline is setup. This is required to prevent a PR validation output (which is not coming from a stable branch) not reaching any environment beyond QA, as the package of PR is coming from a non-existing branch (PR build output is containing current version/* branch code merged with incoming pull request changes, in the build server but not in the target branch yet).

A successfully verified build (created from version/* branch) which is deployed to QA – V can be approved by QA team and is eligible to be deployed to demo or staging (pre-production), with approval from authorized team members.

Production can be only deployed after approval and on demand, as well as after staging environment. The build should be from version/* branch since it is the only possible build to reach the staging environment.

Development environment is set to be deployed on demand without any branch filters, so it allows a build from version/*, feature/* or a PR Build output to be deployed to Dev environment, for developer testing.

With this setup in Azure Build and Release Pipelines and in Azure Git repos branching, branch policy settings we can achieve the simple and effective branching strategy we discussed in the previous post, with Azure DevOps.