Quality Gates in Agile Development
How the classic concept of quality gates is inconspicuously hidden in modern agile development lifecycles
Quality gates, also known as phase-gates, are a fundamental tool in project management, but sound antiquated within a contemporary agile context. In the next few minutes we will demystify the extinction of quality gates and showcase their actual relevance within a modern software development lifecycle.
In project management, quality gates are used to establish well defined transitions between phases of a project. A typical quality gate in a classic software development project, for example, is the number of bugs of allowed before continuing to the next phase, which will most likely be the production phase.
The agile software development lifecycle
Similar to classic projects, the agile software development lifecycle also defines several phases.
Note: The picture above is one of multiple interpretations of the agile development lifecycle.
Two typical quality gates involved in the agile development process are the Definition of Ready (DoR) and the Definition of Done (DoD). The DoR makes sure that all required dependencies are provided before beginning the implementation, thus allowing a smooth sprint and increasing the likelihood of successfully fulfilling the defined sprint goal. The subsequent DoD verifies the successful completion of the implementation phase, ensuring all generic requirements have been met.
Deep dive into the development phase
Software development consists of many more small steps, that could also be titled mini-phases. From a higher level perspective they are too small to visualize in a plan, but are nevertheless an essential part of the workflow.
Let’s deep dive into the development phase and look into the highly utilized GitHub Flow, as a typical process of implementation.
GitHub Flow defines four basic steps
- Create branch from master (aka main or default branch)
- Commit and push changes
- Create pull request
- Merge into master
Introduction of Quality Gates in the development phase
Prior to each following step, there are potential quality gates that are commonly implemented in a professional software development lifecycle.
The pre-commit Quality Gate, facilitating collaboration
- Using a pre-commit hook, the commit message can be checked, or rather forced, to match the respective guidelines, such as including a valid issue-tracking id and defining the nature of the change (feature, bug fix, etc.) before being able to commit the changes. This promotes transparency and supports collaboration, furthermore giving any involved developer the possibility to cherry pick or revert specific changes.
- Linting can also be defined as a mandatory action before being able to commit changes, identifying programming errors, bugs, stylistic errors and suspicious constructs. This makes sure that fellow developers can easily read the code changes and typical errors are unearthed automatically before the actual code review.
- Introducing a compulsory static code analysis will detect potential code smells, giving the programmer the possibility to revise the respective code before initiating peer reviews.
The pre-pull-request Quality Gate, verifying functional quality
- Unit tests have successfully passed
- Defined code coverage has been achieved
- Integration tests have successfully passed
The actions above need no further explanation.
Note: To enable earlier pull request comments without having fulfilled all aforementioned checks, GitHub for example provides the possibility to create draft pull requests. This makes earlier collaboration possible if methods such as pair or mob programming are not feasible.
The pre-merge Quality Gate, assuring fulfillment of four eye principle and security requirements
- Necessary amount of review approvals has been achieved
- All review comments have been successfully resolved, which makes sure that no open questions that emerged during the code review remain unaddressed.
- Dependencies to third party libraries have successfully passed the security check, verifying no libraries with known vulnerabilities are referenced.
Obviously it is up to discussion which check to implement in which Quality Gate, respectively between which phases of development. This strongly depends on the further way of working, such as the level of collaboration and maturity of the involved team. Nevertheless, it is highly recommended to execute checks as early as possible and bring forward every automated check before executing manual checks. For example, having to repeat a code review, because a linter found a superfluous CRLF in a later stage will most likely not generate appreciation among fellow developers.
Conclusion
Quality gates are ever-present in a contemporary development lifecycle. Next to obvious quality gates such as the DoR and the DoD there are several more, merely hidden in plain sight. They are implemented in diverse tools under various names, such as pre-commit hooks, GitHub Checks or GitLab External Status Checks and required jobs in CircleCI workflows. Regardless of which quality gate you decide to implement, it will have a positive effect on the next step or phase, facilitating collaboration, ensuring higher quality and reducing friction.
Not only are quality gates present in an agile development lifecycle, but they are a substantial part of the shift-left of quality assurance. Development is streamlined by bringing automated checks and verifications forward within the development phase, allowing for a more slender and faster subsequent release pipeline.
