Testning av kodkvalitet

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

Introduktion

Kodkvalitetstestningen utvärderar din programkod baserat på en uppsättning kvalitetsregler. Det är det främsta syftet med en rörledning av kodkvalitet och genomförs omedelbart efter byggsteget i alla rörledningar för produktion och icke-produktion.

Se dokumentet Konfigurera CI-CD-pipeline om du vill veta mer om olika typer av rörledningar.

Regler för kodkvalitet

Kodkvalitetstestning söker igenom källkoden för att säkerställa att den uppfyller vissa kvalitetskriterier. Detta implementeras genom en kombination av SonarQube och granskning på innehållspaketnivå med OakPAL. Det finns över 100 regler som kombinerar allmänna Java-regler och AEM-specifika regler. Vissa av de AEM specifika reglerna har skapats baserat på bästa praxis från AEM och kallas för regler för anpassad kodkvalitet.

OBSERVERA

Du kan hämta den fullständiga listan med regler med den här länken.

Tre nivåindelade omdömen

Problem som identifieras med kodkvalitetstestning tilldelas en av tre kategorier.

  • Kritisk - Detta är frågor som orsakar ett omedelbart misslyckande av rörledningen.

  • Viktigt - Detta är problem som gör att pipeline försätts i pausläge. Distributionshanteraren, projektledaren eller företagsägaren kan antingen åsidosätta problemen, i vilket fall pipeline fortsätter, eller så kan de acceptera problemen. I så fall upphör pipeline med ett fel.

  • Info - Det rör sig om frågor som enbart lämnas i informationssyfte och som inte påverkar genomförandet av pipeline

OBSERVERA

I en pipeline med enbart kodkvalitet kan viktiga fel i kodkvalitetsgaten inte åsidosättas eftersom teststeget för kodkvalitet är det sista steget i pipeline.

Klassificeringar

Resultatet av det här steget levereras som Klassificeringar.

I följande tabell sammanfattas klassificerings- och feltrösklarna för var och en av de kritiska, viktiga och informativa kategorierna.

Namn Definition Kategori Feltröskel
Säkerhetsklassificering A = Inga sårbarheter
B = Minst 1 mindre sårbarhet
C = Minst 1 allvarlig säkerhetslucka
D = Minst 1 allvarlig säkerhetslucka
E = Minst en blockerarsårbarhet		 Kritisk < B
Tillförlitlighetsklassificering A = Inga buggar
B = Minst ett mindre fel
C = Minst ett större fel
D = Minst ett kritiskt fel
E = Minst 1 fel i blockering		 Kritisk < D
Underhållbarhetsklassificering Definieras av den utestående reparationskostnaden för koden och luktar som en procentandel av tiden som redan har gått in i programmet
  • A = <=5%
  • B = 6-10 %
  • C = 11-20 %
  • D = 21-50 %
  • E = >50 %
 Viktigt < A
Täckning Definieras av en blandning av radens täckning och villkorstäckning med hjälp av formeln:
Coverage = (CT + CF + LC)/(2*B + EL)
  • CT = Villkor som har utvärderats som true minst en gång under pågående enhetstester
  • CF = Villkor som har utvärderats som false minst en gång under pågående enhetstester
  • LC = Täckta rader = lines_to_cover - uncover_lines
  • B = totalt antal villkor
  • EL = totalt antal körbara rader (lines_to_cover)
 Viktigt < 50%
Överhoppade enhetstester Antal överhoppade enhetstester Information > 1
Öppna ärenden Generella problemtyper - sårbarheter, fel och kodmellanslag Information > 0
Duplicerade rader Definieras som antalet rader som ingår i duplicerade block. Ett kodblock anses duplicerat under följande villkor.
Icke-Java-projekt:
  • Det ska finnas minst 100 efterföljande och duplicerade tokens.
  • Dessa variabler bör spridas över åtminstone
  • 30 kodrader för COBOL
  • 20 kodrader för ABAP
  • 10 kodrader för andra språk
Java-projekt:
  • Det ska finnas minst 10 efterföljande och duplicerade satser oavsett antalet tokens och rader.
Skillnader i indrag och i stränglitteraler ignoreras när dubbletter identifieras.		 Information > 1%
Cloud Service-kompatibilitet Antal identifierade kompatibilitetsproblem med molntjänster Information > 0
OBSERVERA

Se SonarQube's Metric Definition för mer detaljerade definitioner.

OBSERVERA

Mer information om anpassade regler för kodkvalitet som körs av Cloud Manager, se dokumentet Anpassade regler för kodkvalitet.

Hantera med falskt positiva

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

I dessa fall kan källkoden kommenteras med Java-standarden @SuppressWarnings anteckning 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.

OBSERVERA

Även om det är en bra rutin att göra @SuppressWarnings Anteckningen är så specifik som möjligt, d.v.s. kommenterar bara den specifika programsats eller det block som orsakar problemet. Det går att anteckna på klassnivå.

OBSERVERA

Även om det inte finns något uttryckligt steg för säkerhetstestning finns det säkerhetsrelaterade regler för kodkvalitet som utvärderas under steget för kodkvalitet. Se dokumentet Säkerhetsöversikt för AEM as a Cloud Service om du vill veta mer om säkerhet i Cloud Service.

Optimering av skanning av innehållspaket

Som en del av kvalitetsanalysprocessen utför Cloud Manager en analys av innehållspaketen som skapats av Maven-bygget. I Cloud Manager finns optimeringar som snabbar upp den här processen, 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"alla"-paketet, skannas de enskilda innehållspaketen direkt och sorteras baserat på beroenden. Ta till exempel följande byggutdata.

  • all/myco-all-1.0.0-SNAPSHOT.zip (content-package)
  • ui.apps/myco-ui.apps-1.0.0-SNAPSHOT.zip (Skipped-content-package)
  • ui.content/myco-ui.content-1.0.0-SNAPSHOT.zip (Skipped-content-package)

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 innehåller de två inbäddade paketen som tidigare nämnts samt ett eller flera OSGi-paket, och sedan konstrueras ett nytt, minimalt innehållspaket med endast OSGi-paketen. Det här paketet har alltid namnet cloudmanager-synthetic-jar-package och de medföljande paketen placeras i /apps/cloudmanager-synthetic-installer/install.

OBSERVERA
  • Optimeringen påverkar inte de paket som distribueras till AEM.
  • Eftersom matchningen mellan det inbäddade innehållspaketet och det överhoppade innehållspaketet baseras på filnamn, kan optimeringen inte utföras om flera överhoppade innehållspaket har exakt samma filnamn eller om filnamnet ändras vid inbäddning.

På denna sida