This note is in continuation of the previous two notes:
Protect master in Azure Repos using policies
Pull Request Builds in Azure Devops
In my previous notes, I mentioned the steps involve in creating a pull request build. In this note, I am going to extend that idea. Just to recap, previously I mentioned the following options and settings available in Azure DevOps:
(a) when a pull request is submitted a CI build gets triggered. This is to ensure that the incoming code after the merge does not break the CI pipeline.
(b) enable/disable specific steps in a build definition based on conditions. Specifically, we can enable/disable certain steps in a build definition based on whether the build was triggered due to a PR, and if the target branch of the PR is ‘master’.
(c) ensure that a continuous deployment pipeline did not trigger on completion of a CI build that was triggered due to a PR.
However, an instance came up at work where I had to enable the continuous deployment trigger on completion of a PR build but only to one environment. The only way to test the change in the pull request was to deploy it out to an environment. But since it’s a PR (and the change) is not yet merged (in this case to ‘master’) I couldn’t allow other linked environments in the continuous deployment pipeline to get the change deployed. I reviewed the Continuous deployment trigger UI and identified the option available to do so.
If you recollect in the previous note, I had disabled the continuous deployment trigger for a pull request. Here is the specific condition to enable that. I was prompted to provide a target branch -which is ‘master’ in this case. The target branch here is the one for which a PR is raised. I was also provided the message that 0 of 4 stages are enabled for pull request deployments. I had four stages: Dev, Test, Stage, and Prod.
On visiting individual stages I navigated to pre-deployment conditions -> triggers > pull request deployment (that was disabled by default). I enabled that for the Dev stage only. This is important to note. Generally, you do not want a PR build’s deployment to be enabled for all the environments. Enable that only for the purpose of verification and in as few environments as possible.
After saving I navigated back to the pipeline -> artifacts -> continuous deployment trigger and noted that the stage message displayed that 1 of 4 stages are enabled for pull request deployment.
After making this change to the continuous deployment release definition, the process flow will be something like this: A PR gets submitted for master. That PR triggers a CI build. If there are no issues with the code, the CI build succeeds which then triggers a continuous deployment release definition. This release definition deploys the changes in PR to an environment. If environment verification looks good, review the PR, and approve that. On approval, code is merged to the ‘master’ branch which would trigger a CI build. Successful completion of a CI build will then trigger a continuous deployment release definition and as normal flow, the changes will be deployed from an environment to environment.
I tested this scenario and found that the continuous deployment did trigger on a PR CI build completion and deployed the changes to the Dev stage only and not beyond -and that is what was desired. I verified the changes in the Dev environment and was assured that the changes in the PR were aligned with the objective. I then navigated back to the PR review page and approved it. This resulted in a merge to the target branch (‘master’) which triggered a CI build. On completion of CI build, a continuous deployment release definition was triggered which deployed the changes out to all the environments one after the other.
Overall, I like the concept behind branch protection and how the idea manifests via different settings and options available in Azure DevOps. I hope you find these three notes to corroborate with your views on PR builds and releases. Please do mention your views in the comment section below.