The overview of this blog would revolve around covering the below ways of defining the control for enforcing ground rules to be setup prior to pushing code to higher environments.
1. Setting up branch policy in Azure DevOps Repositories given that your code is hosted in Azure DevOps Repository itself.
2. Setting up the GIT Pipeline and the way we can add Gated Checkin given that your code is hosted in GIT platform.
3. Using the Azure DevOps Pipeline’s build definition trigger and options.
Problem Statement : Controlled Checkin to QA branch from Develop(ment) branch in Azure DevOps Services:
Sometimes, we would be required to ensure that only good code seeps into the QA branch and that unverified code doesn’t make it to QA environments. To define the control flow, Azure DevOps has some features which can be utilised to add constraints based on our requirement. To define the control flow in Azure Pipelines, we have the below main features:
1. Setting up branch policy in Azure DevOps Repositories given that your code is hosted in Azure DevOps Repository itself.
Constraining branch policies against particular branches of a given repository or a ‘cross-repository’ branch policies to apply to multiple branches present across repositories
Login to Azure DevOps account. Navigate to Project -> Project Settings -> Repositories tab on left pane -> Policies tab on the mid screen side like shown below :
Here, there ae some self explanatory Repository level policies. I have had fewer git based errors creeping up when committing case insensitive file names and the Repository policy ‘Case Enforcement’ has helped in that regard.
If we scroll down, we can add up a Branch Policy by clicking on ‘+’ icon and we can add up our policy to all branches with a specific name pattern. In below example, I have a develop branch in 2 repositories and this same policy would get applied to both the ‘develop’ branches present in 2 different repositories (EYCompassAPI and EYCompassReact):
Now, in the policy, we add the rules that should be enforced on the 2 ‘develop’ branches. IF we want this policy to be applied to all branches, then we give a * in the above screenshot.
Also, note that if we have the branch policy defined, we cant directly push our changes to the repository from within VS or VS Code (or direct GIT commit either) but rather it has to be done via a Pull Request :
We also have some cool validations like ‘ Build Validation’ which would do a pre build of the merge content using the pipeline you provide without actually merging it.
Basically, I use ‘Minimum’ of 1 Reviewer policy from this cross repository branch policy.
However, one thing to note is that in my case, we have 2 repositories named React and API (React for Frontend code) and API (written in C# for backend functionality). Now, these 2 are build processed using different pipeline build definitions as they obviously require different way of building. [Like API using Nuget Restores and MSBuilds whereas React Repo requires npm builds]
So, given this, we cannot add a ‘Build Validation’ from within Cross Repository branch policies. We would have to opt for Repo specific Branch policy addition which we will see next.
Constraining branch policies against particular branche of a given repository to apply to an individual branch :
In above screen, we select all the branches against a specific repository (EYCompassAPI in this case) and then select the branch policy to only apply branch policies at a granular level only to this particular branch present in this particular repository.
Now, under this, we can enable the ‘Build Validation’ and define the API based pipeline to apply to this API code containing branch that should do the precheck of building this merge and check if it fares well. If it does, then we can go ahead for the actual merge in our Pull Request. Hee, I have provided the displayName of ‘ValidateBuildDevelop’
Now, once a Pull Request is raised, we will see that we have an option to queue the build and do the ‘Build Validation’ check against our pipeline to ensure only Green builds get actually merged into develop branch.
Now, once the validations are successful and code is to be merged to develop, then we can choose the ‘Complete’ option mentioned in top right corner.
Once the Merge is completed, we can opt for Cherry-Picking code into QA(aka push this PR Code conditionally into QA environment) environment.
We can defer Cherry-picking code to QA once the EYCompassReact PR is also available and pushed to develop without any issues. (so an entire functionality comprising of API and React codes are now ready to be pushed to QA).
We can now, cherry pick both the PR’s by selecting the Cherry-pick button in above screenshot (taken off a sample PR).
2. Setting up the GIT Pipeline and the way we can add Gated Checkin given that your code is hosted in GIT platform.
Same set of branch policy checks are also available in GIT and more info can be found in below blog:
If the code is in GIT and the build definition is in Azure Pipelines, then we can modify our YAML file of the build definition by referring below blogpost:
3. Using the Azure DevOps Pipeline’s build definition trigger and options.
Here, we have 2 different type of options while configuring a pipeline, a classis one and a yaml one.
In the above edit of pipeline, we show a classic pipeline’s build options and features :
2 eye catching options available in Build Definition ->Triggers are:
Scheduled and Build Completion options:
Using above option as in screenshot, we can schedule a build on particular date(s) and time(s). However, this isn’t of much use for us as we manually complete PRs and expect our code to get merged based of a PR getting reviewed by the reviewer and not based on a particular timestamp.
If alternatively, we didn’t use the PR approach defined in 1st Main category of this blog, then we would be going with ‘Scheduled’ Builds option to merge code into develop branch along with ‘Build Completion’ option.
Build Completion option here can be defined such that if the ‘develop’ branch build succeeds, then we can automatically trigger build to ‘QA’ environments. However, some of the control features are lost when we opt for the 3rd Main category using this Build Trigger feature as we cant defer cherrypick of ‘develop’ code to QA once both API & React codes are done with (which with 1st main category was with the Reviewers jurisdiction)
Finally, after defining the features we wish using the shown Build trigger, we can convert this build definition to yaml (for using 2nd Main category option of using yaml Azure pipeline definition for GIT hosted Code Repo) by clicking on ‘View YAML’ link as shown below:
Using this YAML Code and appending the gated checkin trigger YAML code as shown in the blogpost : http://thecodemanual.pl/2020/03/26/gated-check-in-build-on-azure-devops-for-dotnet-core-app.html (The trigger element of gated checkin), we can achieve the same functionality with GIT hosted code and Azure Pipeline combination as well.
This concludes this post for defining ways in which we can properly define and enforce control flow rules with ensuring good coding and commit practices.
Komentáře