Unlike traditional CI Systems which only perform a passive monitoring of the quality level of software project branches, non-blocking CI systems are actively involved in the pre-commit qualification process in such manner as to ensure that no regressions occurs in a pre-defined set of QA verification criteria.
"I pulled a fresh workspace from the latest label and ported my changes on it. I built all the images required and passed all tests with flying colours before committing. How come I am blamed for breaking the build? What kind of software development process is this?" You may have heard such arguments from frustrated developers, perhaps repeatedly. In this post we'll look at some common misconceptions revolving around the pre-commit quality verifications.
Traditional CI systems simply monitor the quality level of project branches by periodically performing QA verifications on branch labels in order to detect regressions. In this post we'll look at why such approach can generate congestion, a significant speed limiting factor in the software development, especially for very large scale projects.
What do I mean by "Large Scale Software Development"? Well, I mean software development in environments which have at least one of the following characteristics: