Agile

The Power of Continuous Inspection in Agile Development

In modern, globally distributed development practices, Agile development teams are expected to quickly deliver code that not only compiles, but also adheres to multiple guidelines and compliance factors.

In addition, the source code should be simple enough to be
readable, Atomic in nature so it can be reused on other development projects,
and — last but not least — the code should be testable.

To produce ideal code like this, we must be able to measure
the code quality. We need predefined rules that all code must go through and
come out without any violations of style, vulnerability, bugs or performance.
We also need to measure the various coverage levels, like line coverage, branch
coverage and measure the Cyclomatic complexity as well. Above all, there should
not be any duplication.

To help development organizations, Atos Syntel’s DevSecOps
teams recommends SonarQube to
measure code as part of the Agile development lifecycle. SonarQube supports all
major programming languages, has numerous plugins to support execution through
Continuous Integration, and provides a platform to integrate multiple rules
plugins and repositories to extend the capability to measure noise.

While using a Continuous Integration pipeline, SonarQube enables
us to create a combination of metrics to use as quality gates before the code is
distributed to the target environment. Using SonarQube, we can track and
compare code quality between snapshots and help organizations gradually improve
code quality.

The screenshots below are SonarQube code quality reports
generated in a Java project build through Jenkins-SonarQube integration. Reports
like these provide a quality dashboard for the project for each execution, and
enables us to drill down to code-level violations.

In case a violation or non-compliance is found in the code,
an automated defect should be created in the defect tracking tool against the
development project, as part of the Continuous Inspection process. While
closing the requirements, the development team should ensure all defects are
closed before the requirements are submitted for release.

This process ensures that the development community adheres
to the standard code quality guidelines, and that non-compliant code never
reaches the Dev environment.