Branching, Build and Release Strategy

This post covers the high level branching, build and release strategy for the requirements mentioned in the parent post here . The parent post also covers the actual CI and deployment pipelines for a JavaScript Azure Function mentioned in this post.

We decided to go with Git Flow with the following Build and deployment strategy. Let us consider the pipelines in the following phases:

Sprint Feature Development Phase

Sprint Feature Development

• During a sprint changes for features / tasks are merged into the the develop branch using pull requests
• When a pull request is created the pipeline PR_BUILD_PIPELINE is triggered. This pipeline performs basic sanity checks against the code for the PR like linting, execution of unit tests, checking for adequate code coverage
• If PR build is successful, and after incorporating any Review comments, the PR changes are merged into the develop branch.
• On PR merge in to develop The PUBLISH_RELEASE_ARTIFACTS pipeline is triggered against the develop branch. his pipeline first executes the same checks as PR_BUILD_PIPELINE pipeline, prunes and removes the unwanted dev dependency packages and then publishes the deployable zip artifact, which can be used to release the function app into an environment.
• On demand the RELEASE_TO_ENVIRONMENT pipeline deploys the latest artifacts produced from the develop branch, or a specific build’s artifacts to the development environment Function App.

Release Candidate Features Finalized

Release candidate features finalized

• Before the next sprint starts, and we know which features from the current sprint are in a position to be released, we cut a release branch from the develop. This branch allows us to harden the features for release during the UAT process, while parallelly allowing new features on the next sprint to be merged in the develop branch
• On creation and merging commits into this branch the PUBLISH_RELEASE_ARTIFACTS pipeline is triggered and this time performs the same steps as defined above against the release branch
• On demand the RELEASE_TO_ENVIRONMENT pipeline will deploy the latest artifacts produced from the release branch (or a specific build’s artifacts) to the UAT Function App.

Release candidate UAT complete

Release candidate UAT complete

• Once UAT approval is received, and go ahead is given to move the release candidate changes to production, as per git flow we merge the release candidate branch changes in to the master branch and create a tag for the release. We also merge the changes from the release candidate branch back in to development

Production release

Production release

• On merging commits into the master branch the PUBLISH_RELEASE_ARTIFACTS is triggered and this time performs the same steps as defined above against the master branch
• The PRODUCTION_RELEASE_PIPELINE can be triggered to deploy the published artifacts from master into production. This is a multi-stage pipeline. This pipeline first deploys the specified build artifact from master branch to the staging Function App. Tests are then executed against the staging environment. On manual approval the pipeline then deploys these changes to the production subscription’s pre-prod slot. Some basic checks are performed, and then after manual approval the pre-prod slot and prod slots are swapped, making the changes live
• Hotfixes : Hotfixes branches fork of from master, and merge back into master. Deployment of the hotfixes will be using the same PRODUCTION_RELEASE_PIPELINE pipeline

For details of the actual pipeline please refer the parent post