Kodkvalitetstestning 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

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 Konfigurera CI-CD-pipeline om du vill veta mer om olika typer av pipelines.

Regler för kodkvalitet understanding-code-quality-rules

Kodkvalitetstestning söker igenom källkoden för att säkerställa att den uppfyller vissa kvalitetskriterier. En kombination av SonarQube och granskning på innehållspaketnivå med OakPAL implementerar det här steget. Det finns mer än 100 regler som kombinerar allmänna Java-regler och AEM-specifika regler. Vissa AEM-specifika regler baseras på god praxis från AEM och kallas anpassade regler för kodkvalitet.

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

IMPORTANT
Från och med torsdagen den 13 februari 2025 (Cloud Manager 2025.2.0) använder Cloud Manager Code Quality en uppdaterad version av SonarQube 9.9 och en uppdaterad lista över regler som du kan hämta här.

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

Problem som identifieras med kodkvalitetstestning tilldelas en av tre kategorier.

  • Kritisk - Problem som orsakar ett omedelbart fel i pipeline.

  • Viktigt - Problem som gör att pipeline försätts i pausat läge. En driftsättningshanterare, projektledare eller affärsägare kan antingen åsidosätta problemen, så att pipeline kan fortsätta. Alternativt kan de acceptera problemen, vilket gör att pipelinen avbryts om ett fel uppstår.

  • Info - Problem som tillhandahålls endast i informationssyfte och som inte påverkar pipelinekörningen

NOTE
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 ratings

Resultatet av det här steget levereras som graderingar.

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äkerhetsbedömning
A = Ingen sårbarhet
B = Minst 1 mindre sårbarhet
C = Minst 1 större sårbarhet
D = Minst 1 allvarlig sårbarhet
E = Minst 1 blockerarsårbarhet
Kritisk
< B
Tillförlitlighetsgrad
A = Inga buggar
B = Minst ett mindre fel
C = Minst ett större fel
D = Minst ett kritiskt fel
E = Minst ett fel i en blockerare
Kritisk
< D
Underhållskvalitet

Definieras av den utestående reparationskostnaden för kod luktar som en procentandel av den tid 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 formeln:
Coverage = (CT + CF + LC)/(2*B + EL)

  • CT = Villkor som har utvärderats som true minst en gång under körning av enhetstester
  • CF = Villkor som har utvärderats som false minst en gång under körning av 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
Info
> 1
Öppna ärenden
Generella problemtyper - sårbarheter, fel och kodmellanslag
Info
> 0
Duplicerade rader

Definieras som antalet rader som ingår i duplicerade block. Ett kodblock anses duplicerat under följande villkor.
Projekt som inte är Java:

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

Info
> 1 %
Kompatibilitet med Cloud Service
Antal identifierade kompatibilitetsproblem med molntjänster
Info
> 0
NOTE
Mer detaljerade definitioner finns i SonarQube metric Definitions.
NOTE
Mer information om anpassade regler för kodkvalitet som körs av Cloud Manager finns i Anpassade regler för kodkvalitet.

Hantera med falskt positiva dealing-with-false-positives

Kvalitetsskanningsprocessen är inte perfekt och identifierar ibland felaktigt problem som egentligen inte är problem. Det här läget 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 har en sårbarhet som gör det möjligt att blockera. Men när du har granskat koden inser du att det här problemet 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.

NOTE
Även om det är en god vana att göra @SuppressWarnings-anteckningen så specifik som möjligt - som att bara anteckna den programsats eller det block som orsakar problemet - är det också möjligt att anteckna på klassnivå.
NOTE
Ä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 Säkerhetsöversikt för AEM as a Cloud Service om du vill veta mer om säkerhet i Cloud Servicen.

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 effektiv när vissa paketeringsbegränsningar iakttas. Den viktigaste optimeringen avser projekt som producerar ett enda"allt"-paket, som innehåller flera innehållspaket från bygget, 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.

  • all/myco-all-1.0.0-SNAPSHOT.zip (innehållspaket)
  • ui.apps/myco-ui.apps-1.0.0-SNAPSHOT.zip (överhoppat innehållspaket)
  • ui.content/myco-ui.content-1.0.0-SNAPSHOT.zip (överhoppat innehållspaket)

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 nämndes tidigare och 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.

NOTE
  • Optimeringen påverkar inte de paket som distribueras till AEM.
  • Matchningen mellan inbäddade innehållspaket och överhoppade innehållspaket beror på filnamn. Den här optimeringen kan inte utföras om flera överhoppade paket delar samma filnamn eller om filnamnet ändras under inbäddningen.
recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab