Here’s a plan for team code quality I’ve devised over a several years of working with different applications. Most of these can be done open source.

Each category represents a type of monitoring methodology. This is by no means comprehensive, but is a good guide for the type of project hygiene that has to be done to maintain a good running application.

INPUTS

The input bin of this plan involve what things we look at before we decide to act — data and observable collecting.

Of course any of these tools can be ran in almost any of these stages, but I’ve put them into a best fit bin for matter of brevity.

Monitored Quality

Monitored quality looks at the aspects of the running applications and infrastructure; pretty much runtime state. A lot of devops is involved.

Monitoring of server conditions and application logs, database performance and optimization, specific coverages for OWASP or security breaches. In that monitoring is also running some sort of continuous testing — load type tests (JMeter etc.), performance checks.

Automated Quality

Automated quality we are scanning pre-production code looking for errors.

At this level we have code quality scanning (SonarQube etc.), dependency scanning (Dependency Track etc.), security scanning (BurpSuite etc.), and UI/UX scanning (Lighthouse etc.).

Developer Driven Quality

Developer quality involves tools and observations during the development process — usually on local.

Few developers check their build logs and should (other than runtime)– it’s an endless list of issues. Quality checks before committing — Sonar, linting, AI tools, code coverage — should all be a given. Also, pull requests and code reviews before merging to main branches.

At a higher level — architectural upgrades (watching framework sites for updates, warning from scans, etc.) and developer experience — tools, build times, local issues — should be constantly revisited.

OUTPUTS

Dashboards

Dashboards monitor real time data, especially useful for production support.

Dashboards can be made for Automated Quality and Developer Quality, but generally I consider those part of engineering management and not production monitoring.

Ticket Process

The ticket process involves a triage — to see if the ticket should even be logged.

The inputs come from all three areas, and can product a ton of backlog — sometimes it’s best just to focus on blockers, criticals and majors.