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 erfasst die Software eine Reihe von Metriken. Diese Metriken werden dann mit den vom von der Geschäftsinhaberin oder dem Geschäftsinhaber definierten KPIs (Key Performance Indicators) verglichen. Oder sie werden mit den von Adobe Managed Services festgelegten Standards verglichen.

Diese Ergebnisse 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 Testschritt bewertet die Qualität des Anwendungs-Codes. Dies ist der Hauptzweck einer reinen Code-Qualitäts-Pipeline. Der Testschritt wird unmittelbar nach dem Build-Schritt in allen produktionsfremden und Produktions-Pipelines ausgeführt. Weitere Informationen finden Sie unter Konfigurieren von produktionsfremden Pipelines.

Beim Testen der Code-Qualität wird der Quell-Code gescannt, um sicherzustellen, dass er bestimmte Qualitätskriterien erfüllt.

Die Software implementiert ihn durch eine Kombination aus SonarQube-Analyse, Prüfung auf Inhaltspaket-Ebene mit OakPAL und Dispatcher-Validierung mit dem Dispatcher-Optimierungs-Tool.

Es gibt mehr als 100 Regeln, wobei generische Java-Regeln und AEM-spezifische Regeln kombiniert sind. Einige der AEM-spezifischen Regeln werden auf der Grundlage der Best Practices von AEM Engineering erstellt und werden 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. Dieses Szenario ist als falsch positiv bekannt.

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 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.

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 bei 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 Benutzende virtual-users

Cloud Manager generiert virtuelle Benutzende oder Container basierend auf KPIs (Antwortzeit und Seitenansichten/Min.), die von der Rolle Geschäftsinhaber festgelegt wurden. Diese KPIs werden beim Erstellen oder Bearbeiten des Programms festgelegt.

Je nach definierten KPIs werden bis zu 10 Container generiert, die die tatsächlichen Benutzenden 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

Drei Seitensätze wählen die Seiten aus. Cloud Manager verwendet die Zugriffsprotokolle der AEM-Instanzen in der Produktions- und Staging-Umgebung, um die folgenden 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. Der Traffic wird basiert auf der Anzahl der ausgewählten Sätze verteilt. Das heißt, wenn alle drei ausgewählt sind, werden in jeden Satz 33 % der gesamten Seitenansichten eingefügt. Wenn zwei ausgewählt sind, werden 50 % zu jedem Satz hinzugefügt. Wenn einer ausgewählt ist, werden 100 % des Traffics zu diesem Satz hinzugefügt.

Betrachten wir dieses Beispiel.

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

Test und Bericht testing-reporting

Cloud Manager führt Leistungstests für AEM Sites-Programme durch, indem als nicht authentifizierte Benutzende Seiten über einen 30-minütigen Testzeitraum hinweg standardmäßig auf dem Staging-Veröffentlichungs-Server angefordert werden. Es werden die von virtuellen Benutzenden generierten Metriken (Antwortzeit, Fehlerrate, Ansichten 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 bei Leistungstests von Sites und Assets finden Sie im Abschnitt Authentifizierte Leistungstests.

Authentifizierte Leistungstests authenticated-performance-testing

AMS-Kundinnen und -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 wird in einer string-Variablen und das Kennwort in einer secretString-Variablen gespeichert. Wenn diese beiden Variablen angegeben sind, enthält jede Anfrage des Leistungstest-Crawlers und der virtuellen Testbenutzenden 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 30 Minuten wiederholt hochgeladen werden.

Onboarding-Anforderungen onboarding-requirement

Bei Assets-Leistungstests erstellt Ihr Customer Success Engineer während des Onboardings der Autorin oder des Autors in der Staging-Umgebung einen cloudmanager-Benutzer bzw. eine -Benutzerin (und ein entsprechendes Kennwort). Für die Leistungstestschritte müssen ein Benutzer bzw. eine Benutzerin namens cloudmanager und das zugehörige Kennwort vom CSE eingerichtet werden.

Diese Methode sollte in der Autoreninstanz bleiben und die Berechtigungen sollten nicht geändert werden. Das Ändern oder Entfernen dieser Methode kann dazu führen, dass Assets-Leistungstests fehlschlagen.

Bilder und Assets zum Testen assets-for-testing

Kundinnen und Kunden können ihre eigenen Assets zum Testen hochladen. Dieses Verfahren 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 Aufspaltung von 70/30 verwendet wird und pro Minute 10 Assets hochgeladen werden, werden pro Minute 7 Bilder und 3 Dokumente hochgeladen.

Test und Bericht 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 des 30-minütigen Tests 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.

Die wichtigste Optimierung ist für Projekte, die ein einzelnes „all“-Paket ausgeben, das 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 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.