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

Erfahren Sie, wie das Testen der Code-Qualität von Pipelines funktioniert und wie damit die Qualität Ihrer Bereitstellungen verbessert werden kann.

Einführung introduction

Während der Pipeline-Ausführung werden verschiedene Metriken erfasst und entweder mit den vom Geschäftsinhaber definierten KPIs (Key Performance Indicators) oder mit den von Adobe Managed Services festgelegten Standards verglichen.

Diese werden über ein dreistufiges Bewertungssystem gemeldet.

Dreistufige Bewertungen three-tiered-ratings

Die Pipeline muss drei Akzeptanztests bestehen:

Für jeden dieser Akzeptanztests gibt es eine dreistufige Struktur für vom Test identifizierte Probleme.

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

Dieser Schritt bewertet die Qualität des Anwendungs-Codes. Dies ist der Hauptzweck einer reinen Code-Qualitäts-Pipeline und wird unmittelbar nach dem Build-Schritt in allen produktionsfremden und Produktions-Pipelines ausgeführt. Weitere Informationen finden Sie im Dokument Konfigurieren von produktionsfremden Pipelines.

Beim Testen der Code-Qualität wird der Quell-Code gescannt, um sicherzustellen, dass er bestimmte Qualitätskriterien erfüllt. Dies wird durch eine Kombination aus SonarQube-Analyse, Prüfung auf Inhaltspaket-Ebene mit OakPAL und Dispatcher-Validierung mit dem Dispatcher-Optimierungs-Tool implementiert.

Es gibt über 100 Regeln, die generische Java-Regeln und AEM-spezifische Regeln kombinieren. Einige der AEM-spezifischen Regeln werden auf der Grundlage der Best Practices von AEM Engineering erstellt und als benutzerspezifische Code-Qualitätsregeln bezeichnet.

Die Ergebnisse des Code-Qualitätstests werden als Bewertung bereitgestellt, wie in dieser Tabelle zusammengefasst.

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

Das Verfahren zur Qualitätsprüfung ist nicht perfekt. Mitunter werden fälschlicherweise Probleme identifiziert, die eigentlich nicht problematisch sind. Dies 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 Schwachstelle der Kategorie „Blocker“ hin. Nach Prüfung des Codes erkennen Sie, dass es sich 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 so 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.

Sicherheitstests security-testing

Cloud Manager führt die vorhandenen AEM-Sicherheits-Konsistenzprüfungen in der Staging-Umgebung nach der Bereitstellung aus und meldet den Status über die UI. Die Ergebnisse werden aus allen AEM-Instanzen in der Umgebung aggregiert.

Dieselben Konsistenzprüfungen können jederzeit über die Web-Konsole oder das Vorgangs-Dashboard ausgeführt werden.

Wenn eine der Instanzen einen Fehler bei einer bestimmten Konsistenzprüfung meldet, schlägt die Konsistenzprüfung für die gesamte Umgebung fehl. Wie Code-Qualitäts- und Leistungstests sind diese Konsistenzprüfungen in Kategorien unterteilt und die zugehörigen Berichte werden über das dreistufige Gating-System erstellt. Der einzige Unterschied besteht darin, dass im Falle von Sicherheitstests keine Schwellenwerte vorhanden sind. Alle Konsistenzprüfungen werden entweder bestanden oder schlagen fehl.

In der folgenden Tabelle sind die Konsistenzprüfungen aufgeführt.

Leistungstests performance-testing

AEM Sites aem-sites

Cloud Manager führt Leistungstests für AEM Sites-Programme aus. Der Leistungstest wird etwa 30 Minuten lang ausgeführt, indem durch virtuelle Benutzer (Container) der Zugriff tatsächlicher Benutzer auf Seiten in der Staging-Umgebung und Traffic simuliert wird. Diese Seiten werden mit einem Crawler gefunden.

Virtuelle Benutzer virtual-users

Die Anzahl der virtuellen Benutzer oder Container, die von Cloud Manager erzeugt werden, hängt von den KPIs (Antwortzeit und Seitenansichten/Min.) ab, die der Benutzer in der Rolle Geschäftsinhaber beim Erstellen oder Bearbeiten des Programms definiert hat. Je nach definierten KPIs werden bis zu 10 Container generiert, die die tatsächlichen Benutzer simulieren. Die für Tests ausgewählten Seiten werden aufgeteilt und jedem virtuellen Benutzer zugewiesen.

Crawler crawler

Vor dem Beginn des 30-minütigen Testzeitraums durchsucht Cloud Manager die Staging-Umgebung anhand einer oder mehrerer vom Customer Success Engineer konfigurierten Seed-URLs. Ausgehend von diesen URLs wird der HTML-Code jeder Seite überprüft und Links werden breitenorientiert durchsucht.

Seitensätze zum Testen page-sets

Die Seiten werden nach drei Seitensätzen ausgewählt. Cloud Manager verwendet die Zugriffsprotokolle der AEM-Instanzen in der Produktions- und Staging-Umgebung, um die folgenden drei Buckets zu ermitteln.

Verteilung des Traffics auf ausgewählte Seitensätze distribution-of-traffic

Sie können auf der Registerkarte Testen der Pipeline-Konfiguration zwischen einem Satz und allen drei Sätzen wählen. Die Verteilung des Traffics basiert auf der Anzahl der ausgewählten Sätze, d. h. wenn alle drei Sätze ausgewählt sind, entfallen je 33 % aller Seitenaufrufe auf jeden Satz, bei zwei Sätzen sind es 50 % und bei einem ausgewählten Satz entfallen 100 % des Traffics auf diesen Satz.

Betrachten wir dieses Beispiel.

Für den 30-minütigen Testzeitraum gilt in diesem Fall:

Tests und Reporting testing-reporting

Cloud Manager führt Leistungstests für AEM Sites-Programme durch, indem Seiten über einen 30-minütigen Testzeitraum hinweg standardmäßig als nicht authentifizierter Benutzer auf dem Staging-Veröffentlichungs-Server angefordert werden. Dabei werden die virtuellen, von den Benutzern generierten Metriken (Antwortzeit, Fehlerrate, Aufrufe pro Minute usw.) für jede Seite sowie verschiedene Metriken auf Systemebene (CPU, Arbeitsspeicher, Netzwerkdaten) für alle Instanzen gemessen.

In der folgenden Tabelle finden Sie eine Zusammenfassung der Leistungstestmatrix unter Verwendung des dreistufigen Gating-Systems.

Weitere Informationen zur Verwendung der einfachen Authentifizierung für Leistungstests zum Testen von Sites und Assets finden Sie im Abschnitt Authentifizierte Leistungstests.

Authentifizierte Leistungstests authenticated-performance-testing

AMS-Kunden mit authentifizierten Websites können einen Benutzernamen und ein Kennwort angeben, mit denen Cloud Manager während der Sites-Leistungstests auf die Website zugreift.

Benutzername und Kennwort werden als Pipeline-Variablen mit den Namen CM_PERF_TEST_BASIC_USERNAME und CM_PERF_TEST_BASIC_PASSWORD angegeben.

Der Benutzername sollte in einer string-Variablen und das Kennwort einer secretString-Variablen gespeichert werden. Wenn beide angegeben sind, enthält jede Anfrage des Leistungstest-Crawlers und der virtuellen Testbenutzer diese Anmeldedaten als einfache HTTP-Standardauthentifizierung.

Um diese Variablen mithilfe der Cloud Manager-Befehlszeilenschnittstelle festzulegen, führen Sie Folgendes aus:

$ aio cloudmanager:set-pipeline-variables <pipeline id> --variable CM_PERF_TEST_BASIC_USERNAME <username> --secret CM_PERF_TEST_BASIC_PASSWORD <password>

Informationen zur Verwendung der API finden Sie in der API-Dokumentation Patchen von Benutzer-Pipeline-Variablen.

AEM Assets aem-assets

Cloud Manager führt Leistungstests für AEM Assets-Programme durch, indem Assets für einen 30-minütigen Testzeitraum wiederholt hochgeladen werden.

Onboarding-Anforderungen onboarding-requirement

Bei Assets-Leistungstests erstellt Ihr Customer Success Engineer während des Onboardings des Autors in der Staging-Umgebung einen cloudmanager-Benutzer (und ein entsprechendes Kennwort). Für die Leistungstestschritte müssen ein Benutzer namens cloudmanager und das zugehörige Kennwort vom CSE eingerichtet werden. Dieser sollte weder aus der Autoreninstanz entfernt noch sollten seine Berechtigungen geändert werden. Dies führt wahrscheinlich zu einem Fehler beim Assets-Leistungstest.

Bilder und Assets zum Testen assets-for-testing

Kunden können ihre eigenen Assets zum Testen hochladen. Dies kann bei der Pipeline-Einrichtung oder auf dem Bildschirm Bearbeiten festgelegt werden. Dabei werden typische Bildformate wie JPEG, PNG, GIF und BMP sowie Photoshop-, Illustrator- und Postscript-Dateien unterstützt.

Wenn keine Bilder hochgeladen werden, verwendet Cloud Manager zum Testen ein Standardbild und PDF-Dokumente.

Verteilung von Assets für Tests distribution-of-assets

Die Verteilung der Anzahl von Assets jedes Typs, die pro Minute hochgeladen werden, wird bei der Pipeline-Einrichtung oder auf dem Bildschirm Bearbeiten festgelegt.

Wenn beispielsweise eine Verteilung von 70/30 verwendet wird und pro Minute 10 Dateien hochgeladen werden, werden pro Minute 7 Bilder und 3 Dokumente hochgeladen.

Tests und Reporting testing-and-reporting

Cloud Manager erstellt einen Ordner in der Autoreninstanz und verwendet hierbei den Benutzernamen und das Kennwort, die vom CSE festgelegt wurden. Die Assets werden dann unter Verwendung einer Open-Source-Bibliothek hochgeladen. Die vom Assets-Testschritt ausgeführten Tests werden mit einer -Open-Source-Bibliothek geschrieben. Während der 30-minütigen Testdauer werden sowohl die Verarbeitungszeit für jedes Asset als auch verschiedene Metriken auf Systemebene gemessen. Mit dieser Funktion können sowohl Bilder als auch PDF-Dokumente hochgeladen werden.

Diagramme mit Leistungstestergebnissen performance-testing-results-graphs

Im Dialogfeld Leistungstest sind eine Reihe von Metriken verfügbar.

Die Bereiche mit Metriken können erweitert werden, um ein Diagramm anzuzeigen oder einen Link zu einem Download bereitzustellen oder beides.

Diese Funktion ist für die folgenden Metriken verfügbar.

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. Am wichtigsten ist die Optimierung, die für Projekte durchgeführt wird, die ein einzelnes Inhaltspaket ausgeben, das im Allgemeinen als „all“-Paket bezeichnet wird und eine Reihe andere Inhaltspakete enthält, die durch den Build erzeugt und als übersprungen markiert wurden. 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 sowie 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.