Testning av kodkvalitet code-quality-testing

Lär dig hur kodkvalitetstestning av rörledningar fungerar och hur det kan förbättra kvaliteten på dina distributioner.

Introduktion introduction

Under rörledningen hämtas ett antal mätvärden in och jämförs med nyckeltal (KPI) som definieras av företagsägaren eller med standarder som fastställs av Adobe Managed Services.

Dessa rapporteras med hjälp av ett klassificeringssystem med tre nivåer.

Tre nivåindelade omdömen three-tiered-ratings

Det finns tre portar i pipeline:

För var och en av dessa portar finns det en struktur på tre nivåer för problem som identifieras av porten.

Testning av kodkvalitet code-quality-testing-step

I det här steget utvärderas kvaliteten på programkoden, som är huvudsyftet med en pipeline för enbart kodkvalitet, och utförs omedelbart efter byggsteget i alla icke-produktions- och produktionspipelinjer. Mer information finns i dokumentet Configuring Non-Production Pipelines.

Kodkvalitetstestning söker igenom källkoden för att säkerställa att den uppfyller vissa kvalitetskriterier. Detta implementeras genom en kombination av SonarQube-analys, innehållspaketgranskning med OakPAL och dispatchervalidering med Dispatcher Optimization Tool.

Det finns över 100 regler som kombinerar allmänna Java-regler och AEM-specifika regler. Vissa av de AEM reglerna skapas baserat på bästa praxis från AEM och kallas för Anpassade regler för kodkvalitet.

Resultaten av kodkvalitetstestningen levereras som en klassificering enligt sammanfattningen i denna tabell.

Hantera med falskt positiva dealing-with-false-positives

Kvalitetsskanningsprocessen är inte perfekt och kan ibland felaktigt identifiera problem som inte är problematiska. Detta kallas falskt positivt.

I dessa fall kan källkoden antecknas med Java @SuppressWarnings-standardanteckningen som anger regel-ID som anteckningsattribut. En vanlig positiv sak är att SonarQube-regeln för att identifiera hårdkodade lösenord kan vara aggressiv om hur ett hårdkodat lösenord identifieras.

Följande kod är ganska vanlig i ett AEM projekt, som har kod för att ansluta till en extern tjänst.

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

SonarQube utlöser då en sårbarhet som kan leda till blockering. Men när du har granskat koden inser du att detta inte är någon sårbarhet och kan kommentera koden med rätt regel-ID.

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

Om koden i själva verket var följande:

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

Den rätta lösningen är sedan att ta bort det hårdkodade lösenordet.

Säkerhetstestning security-testing

Cloud Manager kör de befintliga AEM säkerhetshälsokontroller i mellanlagringsmiljön efter distributionen och rapporterar statusen via gränssnittet. Resultaten sammanställs från alla AEM instanser i miljön.

Samma hälsokontroller kan utföras när som helst via webbkonsolen eller kontrollpanelen för åtgärder.

Om någon av instanserna rapporterar ett fel för en viss hälsokontroll misslyckas hälsokontrollen i hela miljön. Precis som för kodkvalitets- och prestandatestning är dessa hälsokontroller ordnade i kategorier och rapporterade med hjälp av ett system med tre nivåer. Den enda skillnaden är att det inte finns något tröskelvärde när det gäller säkerhetstestning. Alla hälsokontroller godkänns eller misslyckas.

I följande tabell visas hälsokontrollerna.

Prestandatestning performance-testing

AEM Sites aem-sites

Cloud Manager kör prestandatestning för AEM Sites-program. Prestandatestet körs i cirka 30 minuter genom att virtuella användare (behållare) som simulerar att faktiska användare kommer åt sidor i stagningsmiljöer för att simulera trafik snurras. Dessa sidor hittas med en crawler.

Virtuella användare virtual-users

Antalet virtuella användare eller behållare som rensas upp av Cloud Manager styrs av nyckeltal (svarstid och sidvisningar/min) som definieras av användaren med rollen Affärsägare när programmet skapas eller redigeras. Baserat på definierade KPI:er kommer upp till 10 behållare som simulerar faktiska användare att rensas. De sidor som väljs för testning delas upp och tilldelas varje virtuell användare.

Crawler crawler

Innan testperioden på 30 minuter börjar kommer Cloud Manager att crawla mellanlagringsmiljön med en uppsättning av en eller flera URL:er som konfigurerats av Customer Success Engineer. Från dessa URL:er granskas HTML på varje sida och länkar gås igenom på bredden först.

Siduppsättningar för testning page-sets

Sidorna markeras med tre siduppsättningar. Cloud Manager använder åtkomstloggarna från de AEM instanserna i olika produktions- och stagingmiljöer för att fastställa följande bukområden.

Distribution av trafik mellan valda siduppsättningar distribution-of-traffic

Du kan välja var som helst från en till alla tre uppsättningar på fliken Testing i din pipeline-konfiguration. Trafikfördelningen baseras på antalet valda uppsättningar. Det vill säga, om alla tre är markerade placeras 33 % av det totala antalet sidvisningar mot varje uppsättning. Om två är markerade går 50 % till varje uppsättning. Om du väljer en sådan går 100 % av trafiken till den uppsättningen.

Låt oss titta på det här exemplet.

Under 30 minuters testperiod:

Testning och rapportering testing-reporting

Cloud Manager kör prestandatestning för AEM Sites-program genom att begära sidor som en oautentiserad användare som standard på publiceringsservern för testperioden i 30 minuter. Den mäter de värden som genereras av virtuella användare (svarstid, felfrekvens, vyer per minut osv.) för varje sida och olika systemnivåmått (CPU, minne, nätverksdata) för alla instanser.

I följande tabell sammanfattas prestandatestmatrisen med hjälp av ett gating-system med tre skikt.

Mer information om hur du använder grundläggande autentisering för prestandatestning för platser och Assets finns i avsnittet Autentiserad prestandatestning.

Autentiserad prestandatestning authenticated-performance-testing

Om det behövs kan AMS-kunder med autentiserade webbplatser ange ett användarnamn och lösenord som Cloud Manager ska använda för att få tillgång till webbplatsen under webbplatstestningen.

Användarnamnet och lösenordet anges som pipeline-variabler med namnen CM_PERF_TEST_BASIC_USERNAME och CM_PERF_TEST_BASIC_PASSWORD.

Användarnamnet ska lagras i en string-variabel och lösenordet ska lagras i en secretString-variabel. Om båda anges kommer alla begäranden från crawlningen av prestandatestet och de virtuella testanvändarna att innehålla dessa autentiseringsuppgifter som grundläggande HTTP-autentisering.

Om du vill ställa in dessa variabler med Cloud Manager CLI kör du:

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

Läs API-dokumentationen för Patch User Pipeline Variables om du vill veta hur du använder API:t.

AEM Assets aem-assets

Cloud Manager kör prestandatestning för AEM Assets-program genom att överföra resurser upprepade gånger under en 30-minuters testperiod.

Krav för introduktion onboarding-requirement

För prestandatestning i Assets kommer din Customer Success Engineer att skapa en cloudmanager-användare och ett lösenord när författaren kommer till mellanlagringsmiljön. Prestandateststegen kräver en användare med namnet cloudmanager och det associerade lösenordet som har konfigurerats av din CSE. Detta bör varken tas bort från författarinstansen eller dess behörigheter ändras. Om du gör det kommer Assets prestandatestning troligtvis att misslyckas.

Bilder och Assets för testning assets-for-testing

Kunderna kan överföra egna resurser för testning. Detta kan du göra på skärmen Inställningar för pipeline eller Redigera. Vanliga bildformat som JPEG, PNG, GIF och BMP stöds tillsammans med Photoshop-, Illustrator- och Postscript-filer.

Om inga bilder överförs använder Cloud Manager en standardbild och PDF-dokument för testning.

Distribution av Assets for Testing distribution-of-assets

Distributionen av hur många resurser av varje typ som överförs per minut anges på skärmen Inställningar för pipeline eller Redigera.

Om t.ex. en delning på 70/30 används och det finns 10 resurser överförda per minut, överförs 7 bilder och 3 dokument per minut.

Testning och rapportering testing-and-reporting

Cloud Manager skapar en mapp på författarinstansen med hjälp av användarnamnet och lösenordet som anges av CSE. Assets överförs sedan till mappen med ett bibliotek med öppen källkod. Testerna som körs av Assets teststeg har skrivits med ett bibliotek med öppen källkod. Både bearbetningstiden för varje resurs och olika mätvärden på systemnivå mäts över testperiodens 30 minuter. Den här funktionen kan överföra både bilder och PDF-dokument.

Resultatdiagram för prestandatestning performance-testing-results-graphs

Ett antal mätvärden är tillgängliga i dialogrutan Prestandatest

Måttpanelerna kan expanderas för att visa ett diagram, ge en länk till en hämtning eller båda.

Den här funktionen är tillgänglig för följande mätvärden.

Optimering av skanning av innehållspaket content-package-scanning-optimization

Som en del av kvalitetsanalysprocessen gör Cloud Manager en analys av de innehållspaket som skapats av Maven-bygget. Cloud Manager erbjuder optimeringar som snabbar upp denna process, som är effektiva när vissa paketeringsbegränsningar iakttas. Det viktigaste är optimeringen som utförs för projekt som genererar ett enstaka innehållspaket, som vanligtvis kallas"all"-paket, som innehåller ett antal andra innehållspaket som skapats av bygget och som markeras som överhoppade. När Cloud Manager identifierar detta scenario, i stället för att packa upp"all"-paketet, skannas de enskilda innehållspaketen direkt och sorteras baserat på beroenden. Ta till exempel följande byggutdata.

Om de enda objekten i myco-all-1.0.0-SNAPSHOT.zip är de två överhoppade innehållspaketen skannas de två inbäddade paketen i stället för innehållspaketet "all".

För projekt som producerar dussintals inbäddade paket har den här optimeringen visat sig spara upp till 10 minuter per pipeline-körning.

Ett specialfall kan inträffa när innehållspaketet "all" innehåller en kombination av överhoppade innehållspaket och OSGi-paket. Om myco-all-1.0.0-SNAPSHOT.zip till exempel innehåller de två inbäddade paketen som tidigare nämnts samt ett eller flera OSGi-paket, skapas ett nytt, minimalt innehållspaket med endast OSGi-paketen. Det här paketet har alltid namnet cloudmanager-synthetic-jar-package och de inkluderade paketen placeras i /apps/cloudmanager-synthetic-installer/install.