Testen der Code-Qualität code-quality-testing

Hier finden Sie Informationen dazu, wie das Testen der Code-Qualität von Pipelines funktioniert und wie sich damit die Qualität Ihrer Bereitstellungen verbessern lässt.

Einführung introduction

Beim Testen der Code-Qualität wird Ihr Programm-Code anhand eines Satzes von Qualitätsregeln bewertet. Dabei handelt es sich um das Kernziel einer reinen Code-Qualitäts-Pipeline, die unmittelbar nach dem Erstellungsschritt in allen produktionsfremden und Produktions-Pipelines ausgeführt wird.

Weitere Informationen zu den verschiedenen Pipelines finden Sie unter Konfigurieren Ihrer CI/CD-Pipeline.

Code-Qualitätsregeln understanding-code-quality-rules

Beim Testen der Code-Qualität wird der Quell-Code gescannt, um sicherzustellen, dass er bestimmte Qualitätskriterien erfüllt. Dieser Schritt wird durch eine Kombination aus SonarQube und der Prüfung auf Inhaltspaketebene mit OakPAL implementiert. Es gibt mehr als 100 Regeln, die generische Java-Regeln und AEM-spezifische Regeln kombinieren. Einige AEM-spezifische Regeln basieren auf Best Practices aus dem AEM Engineering und werden als benutzerspezifische Code-Qualitätsregeln“.

Sie können die aktuelle vollständige Liste von Regeln über diesen Link herunterladen.

Dreistufige Bewertungen three-tiered-gate

Probleme, die durch das Testen der Code-Qualität erkannt werden, werden einer von drei Kategorien zugewiesen.

Bewertungen ratings

Die Ergebnisse dieses Schritts werden als Bewertungen bereitgestellt.

In der folgenden Tabelle sind die Bewertungen und Fehlerschwellenwerte für die einzelnen Kategorien „Kritisch“, „Wichtig“ und „Information“ zusammengefasst.

Umgang mit falsch positiven Treffern dealing-with-false-positives

Das Verfahren zur Qualitätsprüfung ist nicht perfekt und benennt mitunter Probleme, die tatsächlich nicht problematisch sind. Dieser Status wird als falsch positiv bezeichnet.

In diesen Fällen kann der Quell-Code mit der standardmäßigen @SuppressWarnings-Java-Anmerkung kommentiert werden. Dabei wird die Regel-ID als Anmerkungsattribut angegeben. Ein häufiges Problem besteht etwa darin, dass die SonarQube-Regel zur Erkennung hartcodierter Kennwörter in Bezug auf die Identifizierung eines hartcodierten Kennworts „aggressiv“ sein kann.

Der folgende Code ist in einem AEM-Projekt, das eine Verbindung zu einem externen Service herstellen soll, relativ häufig.

@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

SonarQube weist dann auf eine „Blocker“-Schwachstelle hin. Nach Prüfung des Codes erkennen Sie jedoch, dass es sich bei diesem Problem nicht um eine Schwachstelle handelt, und kommentieren dies mit der entsprechenden Regel-ID.

@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

Wenn der Code allerdings tatsächlich wie folgt lautete:

@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";

Dann bestünde die richtige Lösung darin, das hartcodierte Kennwort zu entfernen.

Optimierung der Inhaltspaketüberprüfung content-package-scanning-optimization

Im Rahmen des Qualitätsanalyseprozesses führt Cloud Manager eine Analyse der vom Maven-Build erzeugten Inhaltspakete durch. Cloud Manager bietet Optimierungen zur Beschleunigung dieses Prozesses an, die wirksam sind, wenn bestimmte Verpackungseinschränkungen beachtet werden. Die wichtigste Optimierung betrifft Projekte, die ein einzelnes „all“-Paket erstellen, das vom Build her mehrere Inhaltspakete enthält, die als „übersprungen“ markiert sind. Wenn Cloud Manager dieses Szenario erkennt, wird nicht das gesamte Paket entpackt, sondern die einzelnen Inhaltspakete werden direkt gescannt und auf der Grundlage von Abhängigkeiten sortiert. Betrachten Sie zum Beispiel die folgende Build-Ausgabe.

Wenn die beiden übersprungenen Inhaltspakete die einzigen Elemente innerhalb von myco-all-1.0.0-SNAPSHOT.zip sind, werden die beiden eingebetteten Pakete anstelle des gesamten Inhaltspakets („all“) gescannt.

Bei Projekten, die Dutzende von eingebetteten Paketen produzieren, kann diese Optimierung nachweislich bis zu 10 Minuten pro Pipeline-Ausführung einsparen.

Ein Sonderfall kann eintreten, wenn das Inhaltspaket „all“ eine Kombination aus übersprungenen Inhaltspaketen und OSGi-Bundles enthält. Wenn myco-all-1.0.0-SNAPSHOT.zip beispielsweise die beiden zuvor erwähnten eingebetteten Pakete und ein oder mehrere OSGi-Bundles enthält, wird ein neues, minimales Inhaltspaket nur mit den OSGi-Bundles erstellt. Dieses Paket hat immer die Bezeichnung cloudmanager-synthetic-jar-package und die darin enthaltenen Bundles werden in /apps/cloudmanager-synthetic-installer/install abgelegt.