(2022-July-25) I really liked reading printed PC Magazines (https://www.pcmag.com/) or Computerworld newspapers (https://www.computerworld.com/) when I was in school. Those magazines pictured IT System or Database Admins as a special group of IT professionals. Big IT vendor paper ads usually portrayed them in a clean business-casual dress code with button-down collar shirts being surrounded by tall server racks with flickering lights. On another side, if you were part of the development or data analyst team without sufficient knowledge of IT infrastructure maintenance and management practice, then connecting with such an elite workforce team and seeking their help was slightly difficult, however, that wasn’t always the case.
Things change: print editions of magazines are discontinued and the dress code is no longer a required sign of an IT group membership. So in real life, one of the ways to fight this “imposter” syndrome is to step out of my comfort zone and learn new things related to database administration, security and network configuration. Which are not necessarily required in my current job, but they help to build confidence in the areas where I used to know the least and see what else I would need to formulate in my further request for help.
Photo by Mohamed Rizly: https://www.pexels.com/photo/a-person-holding-a-needle-with-yarn-10566047/
This post is a good example of my testing the ice in the DevOps area that I don’t have much experience with, but who said that I can’t get one :- )
I had an idea to establish a workflow of committing and merging development code changes from feature code branches to one development branch, running all the tests, resolving possible conflicts and then only allowing code merges from this development branch to the main one.
It is possible to establish such a workflow by training a development team to follow these code merge steps: feature branch => development branch => main branch. However, as a human, I tend to make mistakes, and during working on ideas for this blog post, I almost purged my main code branch simply because I didn’t have proper policies in place. So I needed some automation and protection in place.
Azure DevOps doesn’t have such functionality out of the box. But I still needed to use Azure DevOps to build a CI/CD pipeline. Is it still possible? The short answer is Yes, let me take a few paragraphs to explain how.
First, I created a build pipeline with a simple “Command Line Script”. I named it “Dev-to-Main-code-merge-check”, but the name doesn’t matter, but the pipeline actions matter. Then I placed an erroneous command script to execute as a simple text string, “Error: Code should be merged from Development to the Main branch”. This script command could be anything harmless, but it has to fail. And then I placed a condition that this script command can only be executed when a pull request comes from any code branch except the development branch: ne(variables['System.PullRequest.SourceBranch'], 'refs/heads/development').
steps:
- script: '"Error: Code should be merged from Development to the Main branch"'
failOnStderr: true
displayName: 'Command Line Script'
condition: ne(variables['System.PullRequest.SourceBranch'], 'refs/heads/development')
The second thing that I did, was to add a new policy to my main branch with the build validation using the build pipeline from my first step. This will ensure the execution of the “Dev-to-Main-code-merge-check” build pipeline whenever a pull request is created to merge code to the main branch.
Testing time
Whenever a pull request to merge code to the main branch was done NOT from the development branch, then the “Dev-to-Main-code-merge-check” build pipeline would be executed and the Command line task would fail, thus preventing further code merge to the main branch.
Whenever a pull request to merge code to the main branch was done from the development branch, then the “Dev-to-Main-code-merge-check” build pipeline would still be executed and the Command line task would be skipped due to the existing condition, thus allowing further code merge to the main branch.
This is how the (feature branch => development branch => main branch) workflow was enforced in my Azure DevOps environment. Please leave a comment if you wish to discuss this approach more. Any criticism would be welcomed!