CI/CD series – OverOps: How ‘code quality gates’ optimise the pipeline
This is a guest post for the Computer Weekly Developer Network in our Continuous Integration (CI) & Continuous Delivery (CD) series.
This contribution is written by Chen Harel in his role as VP of product at OverOps — the company is known for its work focused on enabling companies who create software to ensure rapid code changes do not impact customer experience.
Reminding us that there’s a slightly scary notion in the world of software development, harel urges us to think about the so-called “Rule of Ten”.
Harel writes as follows…
Its premise is simple: the cost of finding and fixing software defects increases 10X the further you progress through the software delivery lifecycle.
For anyone tasked with building and delivering software, this is a terrifying thought.
Many of us have seen first-hand how software bugs in a production environment can translate to millions lost in customer transactions, brand tarnishment and developer productivity. The implications of a customer-impacting incident seem to grow more serious by the day.
As a result [of the impact of heinous software bugs], many teams are adopting what’s called a ‘shift-left’ approach, focusing their attention to quality earlier in the software delivery lifecycle to help detect bugs when they are least costly.
While most organisations adopt CI/CD tooling and practices for the purpose of agility, if done correctly, CI/CD can also play a crucial role in making these shift-left quality initiatives successful. After all, you can keep pumping code through your shiny new pipeline at breakneck speed, but if it’s poor quality code you’re just accelerating a lot of operational headaches.
Code Quality Gates
Incorporating test automation in your CI/CD pipeline can increase release velocity without jeopardising the production environment or creating technical debt – as long as you’re analysing your code for the right things. After making sure you have meaningful tests and code coverage, I’ve found that the best way to optimise a CI/CD pipeline for quality is by gating your builds based on severe error types. The concept of quality gates isn’t new, but this particular application within the CI/CD pipeline is one of its more powerful uses.
For my team, it’s the key to preventing Sev1s — so some examples of useful quality gates include:
- New Errors – Did the release introduce any errors that didn’t previously exist?
- Increasing Error Rate – Did the rate of a known error increase dramatically in this release?
- Slowdowns – Did the release introduce any slow or failing transactions?
These gates should be configured based on the code-level issues that matter to your application. If you aren’t sure what the right threshold is, there are numerous open source plugins that provide out of the box recommended quality gates you can later configure as you continue to learn how different issues impact your system.
Commit to committal
By evaluating thresholds of this nature within your CI/CD pipeline, you gain several advantages. Each code commit allows you begin testing pieces of code for an upcoming release earlier in the process, increasing the speed of feedback and leaving more time to find and fix defects without disrupting deadlines.
It also reduces reliance on traditional manual testing methods and adds accountability to your development team without derailing release progress or sparking finger-pointing.
CI/CD is more than just a means of increasing agility. With the right quality gates, it can mean the difference between hoping your code will work in production… and knowing that it will.