Simple and Effective Branching and Deployment Strategy

While using Git repos there many standard branching strategies teams follow. With this post let’s discuss a simple to understand and execute branching and deployment strategy, which supports most of the requirements, a software development and delivery team requires. The following implementation is considering the Azure Git Repos and Azure Pipelines in Azure DevOps. However, you might be able to implement the same with other Git repos and CI/CD tools.
Let’s have a look at pictorial representation of the proposed strategy first.

Here we talk about three branch types.

• Master – The stable master branch which we never deploy from. After each release is made to production, we merge changes of that release from version branch to the master via a pull request.
• Version – When starting development for each client release a version branch is created from master, say version/0.0.1
• Feature – When start working on each new feature or bug fix a new branch should be created from the version branch (version which is to be released). It could be a version that is already in production, if the bug is a hot fix to the production.

Build

• CI Build – A build setup to build, run unit tests and create a deployable package on every push to master, version or feature branch.
• PR Build – Using the same CI Build applying version branch protection policy so that any incoming Pull Request can be merged only if the build succeeds, with current version branch applied with incoming changes.

Environments

• Dev – Developers test environment where on demand any feature build, version build or PR build can be deployed.
• ATST – Automated test target environment which will be deployed with each PR build or version build upon completion of the build. Then the test automations will be executed against this environment. On success it will trigger the QA deployment and wait for approval.
• QA – QA team will take in deployments from PR builds or version builds by approving release. PR builds will only allow pull requests to be tested in QA environment. But a PR build cannot be deployed beyond QA environment as it is not having actual source code available in a branch. Once QA team is happy with the pull request functionality, they will merge the PR to version branch. A version branch release is also tested in QA after the automated test environment, and with approval can be deployed to Demo or Staging (STG/UAT).
• Demo – QA Approved version branch build can only be deployed to Demo environment.
• STG (UAT) – QA Approved version branch build can only be deployed to STG environment where end users will do final tests before allowing it to be deployed to production.
• PROD – The production environment that can only be deployed with approval to STG environment.

In the next post, let’s try to explore how to implement above strategy with Azure Git repos, Builds and Release pipelines.