D
DonKoning
Introduction
In the fast-paced realm of DevOps, collaboration is paramount. However, as every team member brings their unique coding and documentation style to the table, achieving consistency can be a recurring challenge. Establishing and enforcing coding standards, often documented in lengthy Wiki pages or style guides, seems like a logical solution. But, as the saying goes, 'TL;DR' becomes the norm, leading to a cycle of confusion and inconsistency.
In this blog post, I want to share my approach to achieving code consistency through automation.
In the role of Platform DevOps engineer, my primary responsibilities involve working with various types of code, including PowerShell, ARM templates, Bicep, JSON, YAML, Terraform scripts, and markdown documentation. As a way to enforce our coding standards, my objective was to implement a solution in Azure DevOps that will automatically analyze any code changes every time a Pull Request is submitted and also report back any actionable feedback it finds so I can fix any issues.
What is a linter
A linter is a static code analysis tool that automatically reviews source code to identify and flag potential issues, inconsistencies, or violations of coding standards and best practices. It enforces coding conventions and helps maintain code quality by detecting errors, such as syntax errors, code style violations, and suspicious constructs, before the code is executed.
I'm well aware that we could and should shift left even more by running these checks locally in our IDE's before committing any code. This solution doesn't prevent you from doing so, but it does provide that final check, just to be sure.
During my research, I came across two noteworthy solutions: Super-Linter and MegaLinter (a Super-Linter hard-fork). Both of these solutions offer a comprehensive suite of linters bundled into a single package. Personally, I found MegaLinter to be the preferable choice for a couple of key reasons. Firstly, enhanced speed, as it has the capability to run multiple linters in parallel. More importantly, MegaLinter can automatically incorporate the linting results as comments in your Pull Requests (PRs), making them readily available.
While there are many other interesting features within these tools, I won't delve into them in this blog post. However, I highly recommend exploring these additional capabilities.
The plan
The goal was to implement MegaLinter with minimal effort, especially since our project has a substantial number of repositories. I aimed to avoid the laborious task of modifying pipelines in each individual repository to accommodate the MegaLinter configuration. Instead, I chose to create a dedicated central repository with a pipeline and configuration files – IMHO a more streamlined and manageable approach, even though during implementation I learned this is not the most common approach.
Assumption(s)
The solution assumes you have a single Azure DevOps organization and a single project with multiple git repositories in Azure DevOps.
The solution
The solution is based on a central repository dedicated to MegaLinter. This repo contains a pipeline and configuration file for MegaLinter itself and configuration files for the linters you want to use.
By leveraging branch policies, the pipeline in the central repo is invoked whenever a PR is submitted for any repository (sources). The pipeline clones the branch of the source repository and determines which files were modified. It then gets the ID of the PR, so that we can use it to report the results back to the PR request.
When all prerequisites are met, MegaLinter is invoked, passing the parameter with file(s) to check and finally the Mega-Linter reports are uploaded as artifacts in addition to the summary report back to the PR.
Summary
Incorporating automated code analysis into your DevOps workflow can enhance code quality, reduce inconsistencies, and streamline the PR review process, ultimately leading to a more efficient and collaborative way of working.
Try for your self
Ready to boost code consistency in your DevOps projects with automated code analysis tools like MegaLinter? Give it a try and share your experiences in the comments below.
I've published a sample public repository on GitHub. The readme contains step-by-step instructions how to implement this solution in your own Azure DevOps environment.
Disclaimer
The sample scripts are not supported by any Microsoft standard support program or service. The sample scripts are provided AS IS without a warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Continue reading...
In the fast-paced realm of DevOps, collaboration is paramount. However, as every team member brings their unique coding and documentation style to the table, achieving consistency can be a recurring challenge. Establishing and enforcing coding standards, often documented in lengthy Wiki pages or style guides, seems like a logical solution. But, as the saying goes, 'TL;DR' becomes the norm, leading to a cycle of confusion and inconsistency.
In this blog post, I want to share my approach to achieving code consistency through automation.
In the role of Platform DevOps engineer, my primary responsibilities involve working with various types of code, including PowerShell, ARM templates, Bicep, JSON, YAML, Terraform scripts, and markdown documentation. As a way to enforce our coding standards, my objective was to implement a solution in Azure DevOps that will automatically analyze any code changes every time a Pull Request is submitted and also report back any actionable feedback it finds so I can fix any issues.
What is a linter
A linter is a static code analysis tool that automatically reviews source code to identify and flag potential issues, inconsistencies, or violations of coding standards and best practices. It enforces coding conventions and helps maintain code quality by detecting errors, such as syntax errors, code style violations, and suspicious constructs, before the code is executed.
I'm well aware that we could and should shift left even more by running these checks locally in our IDE's before committing any code. This solution doesn't prevent you from doing so, but it does provide that final check, just to be sure.
During my research, I came across two noteworthy solutions: Super-Linter and MegaLinter (a Super-Linter hard-fork). Both of these solutions offer a comprehensive suite of linters bundled into a single package. Personally, I found MegaLinter to be the preferable choice for a couple of key reasons. Firstly, enhanced speed, as it has the capability to run multiple linters in parallel. More importantly, MegaLinter can automatically incorporate the linting results as comments in your Pull Requests (PRs), making them readily available.
While there are many other interesting features within these tools, I won't delve into them in this blog post. However, I highly recommend exploring these additional capabilities.
The plan
The goal was to implement MegaLinter with minimal effort, especially since our project has a substantial number of repositories. I aimed to avoid the laborious task of modifying pipelines in each individual repository to accommodate the MegaLinter configuration. Instead, I chose to create a dedicated central repository with a pipeline and configuration files – IMHO a more streamlined and manageable approach, even though during implementation I learned this is not the most common approach.
Assumption(s)
The solution assumes you have a single Azure DevOps organization and a single project with multiple git repositories in Azure DevOps.
The solution
The solution is based on a central repository dedicated to MegaLinter. This repo contains a pipeline and configuration file for MegaLinter itself and configuration files for the linters you want to use.
By leveraging branch policies, the pipeline in the central repo is invoked whenever a PR is submitted for any repository (sources). The pipeline clones the branch of the source repository and determines which files were modified. It then gets the ID of the PR, so that we can use it to report the results back to the PR request.
When all prerequisites are met, MegaLinter is invoked, passing the parameter with file(s) to check and finally the Mega-Linter reports are uploaded as artifacts in addition to the summary report back to the PR.
Summary
Incorporating automated code analysis into your DevOps workflow can enhance code quality, reduce inconsistencies, and streamline the PR review process, ultimately leading to a more efficient and collaborative way of working.
Try for your self
Ready to boost code consistency in your DevOps projects with automated code analysis tools like MegaLinter? Give it a try and share your experiences in the comments below.
I've published a sample public repository on GitHub. The readme contains step-by-step instructions how to implement this solution in your own Azure DevOps environment.
Disclaimer
The sample scripts are not supported by any Microsoft standard support program or service. The sample scripts are provided AS IS without a warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Continue reading...