Why is a Quality Gate needed in a DevOps pipeline?
To understand the need of a Quality Gate, let's backtrack it. Let's first understand the code review approaches & how the world would be without a Quality Gate. We all know that...
"Do not compromise on the quality and your customers will not negotiate on the price." Amit Kalantri, author
This article is not about what a Quality Gate is. It's about understanding the need of a Quality Gate in the DevOps pipeline. If you don't have an idea about Quality Gates, I would suggest to read some articles on the internet first.
Ok. Here we go.
To understand the need of a Quality Gate, let's backtrack it. Let's first understand the code review approaches & how the world would be without a Quality Gate.
Code review is a process which almost all the companies follow in today's market. On a broader level, below are 3 types of code reviews -
- Manual review
- Automated review using IDE tools
- Automated review using Quality Gate
Below is a typical process of manual review in a DevOps environment -
This process requires dedicated efforts of a resource for doing the code review. Suppose John is the person who is the code reviewer of the team. He is highly skilled & doesn't miss even a single line of poor code(which, by the way, is not practically possible). He gets a good opportunity with another company & resigns. What would the current company do? It will hire another resource. Problem solved. Right?
Even though the new hire is a great talent but it's no guarantee that he will match the exceptional skills of John. And there in lies the problem!
The manual code review is HIGHLY dependent on the reviewer's knowledge & skillset.
Let's suppose that the new hire, Kenny, is equivalent to John in terms of knowledge. Now almost every company maintains a code review document for the uniform rules across the company which acts as a single source of truth. Kenny will need to go through that document & grasp the details so that he can review the code as per the company's accepted standards. Given the dynamic market of IT, code review standards keep updating & the code review document will also need to be updated at regular intervals. It gives us the next problem in manual review process.
The Single Source Of Truth for code review standards within a company needs to be maintained & updated rigorously.
Let's suppose that the company maintains & updates the code review document consistently. So the company now has Kenny who is an excellent replacement of John & it also keeps updating the single source of truth in timely manner. Where is the issue now? The issue lies in costing!
Kenny will be required to put his sound knowledge & efforts in reviewing the code manually, which could have been used somewhere else in more productive areas. Company will also need to align some process/resource for manually updating the code review document on a timely basis. It will also require dedicated time to execute these set of exercises. You see, these factors would contribute in increasing the cost & reducing the productivity!
Manual code review increases the cost of the project & reduces the overall productivity of the team.
Though there are many other disadvantages of manual code review but from the above mentioned examples you get the drift I believe. Due to so many negative points, there was a need which could reduce the manual intervention in reviewing the code.
And lo & behold, enters the automated code review IDE based tools!
These are the tools which takes productivity to a higher level by reducing the manual intervention during code review process. The idea is simple. The tool gets integrated in the development IDE & consists of set of rules as per the current market coding standards. It provides hints/suggestions in the IDE itself to developers while he codes! There are many IDE based tools available today in market like -
Above examples are from a .Net developer perspective, but there are enough tools for almost every language/platform in the market. Below is a high level diagram for the IDE tool based code review process -
This approach does provide increased productivity & better resource utilization. But there are still some flaws which need attention.
Suppose SonarLint tool is decided to be used within a team. Vicky, a .Net developer, does some code changes & checks for the SonarLint suggestion in VS2019 IDE. He sees 4 hints & incorporates only 2 & leave out the other suggestions. Yes he can choose NOT to implement the tool's suggested inputs. The poor code makes way to the reviewer table. Now reviewer takes latest code on his machine & checks for the tool's suggested hints to verify if the developer has followed the practices. He finds that the developer indeed has missed 2 hints which he should have implemented. But the reviewer has to attend to other high priority tasks & does not want to reject this PR due to the criticality of the ticket. He approves it & the same poor code makes way to the deployment journey. This scenario gives us our first problem in this approach.
The tool does not ENFORCE anyone to follow the standard code rules.
You see now. Even though we used automated tool, it still did not fully resolve our problem. And the solution is to automate it more as the quality of the project is still dependent on the manual decisions.
Now to resolve it, the team decides to implement additional task in DevOps which will check if the tool has any suggestions/hints & if yes it will fail the build, protecting the environment from the bad code. Problem resolved. Right? To some extent, yes. But it introduces a new unwanted scenario.
Suppose a ticket comes which is highly critical & has to be pushed to live environment ASAP. Vicky does the code changes by spending extra hours & does not check for SonarLint suggestions due to the time constraint. Once the PR is raised, the DevOps pipeline build gets triggered but gets failed due to the additional task we created for verifying the tool's hints. Now Vicky will need to implement the tool's hints anyhow to clear the build's process which will again require some time resulting in the delay of that critical ticket's delivery.
IDE based tools are a great fit for IDE only & not for DevOps pipeline.
So the time demanded an approach, a tool which would nicely fit in a DevOps pipeline as well as provide flexibility to push bad code in live environment but records it somewhere to target it in next releases. Enter Quality Gates!
Quality Gates provide a perfect combination of quality checks & the flexibility to adjust to quality checks scenarios.
Consider that Vicky's team decide to put Quality Gate, say SonarCloud, in DevOps pipeline & set the coding rules as -
Fail the Quality Gate when no. of code smells > 5
And also they set SonarCloud quality gate check as optional in the DevOps pipeline so that the failed quality gate does not block the tickets to move to next stage.
Now take a moment & realize the power of this approach. Vicky can look at the suggestions in the IDE with the help of SonarLint & can decide to skip 6 hints due to time constraints. He raises the PR & the DevOps pipeline shows that SonarCloud check is failed but as that check is optional it does not block his ticket. The reviewer reviews & approves it quickly as the ticket is critical. The ticket then goes to production by moving through the next stages. Now the power here is that even though the bad code makes way to live environment, SonarCloud has it recorded. The team/stakeholders can go to SonarCloud management & check the overall project health, and can see that it has n no. of code smells in the code which should be planned for resolution in the coming releases.
Quality Gate not only provides code review but provides code coverage, security review & many other factors as well. It provides an overall 360 degree overview of the project health.
Quality Gate IS NOT EQUAL to Automated Code Review.
Read the above sentence again. Let it sink.
We must understand that the Quality Gate is not just an automated code review tool which most of the folks understand it to be. It's a whole different beast altogether.
I would suggest to do a hands on SonarCloud to have a better understanding of it's capabilities.
By now you would have realized that these approaches are not interchangeable but each just have a separate use case. Use all the 3 approaches to have a higher degree of quality in your project.
- Use manual review for the areas which cannot be covered by any tool like impact analysis, design patterns etc.
- Use IDE based tool for reducing the bad code while coding itself.
- Use quality gate for protecting the main code & recording the project health to prepare a roadmap out of it.
Below is a high level diagram with using all the approaches in a typical DevOps environment -
Though there are many other use cases & needs of a Quality Gate but I just wanted to put forth some ideas so that you guys can have a bit better clarity on this.
Hope you have enjoyed the article.