Testen van de codekwaliteit code-quality-testing
Leer hoe het testen van de codekwaliteit van pijpleidingen werkt en hoe het de kwaliteit van uw plaatsingen kan verbeteren.
Inleiding introduction
Bij het testen van de codekwaliteit wordt uw toepassingscode geëvalueerd op basis van een set kwaliteitsregels. Het is het primaire doel van een code-kwaliteit slechts pijpleiding en wordt uitgevoerd onmiddellijk na de bouwstap in alle productie en niet-productiepijpleidingen.
Zie Vormend Uw CI-CD Pijpleidingom meer over verschillende soorten pijpleidingen te leren.
Codekwaliteitsregels understanding-code-quality-rules
Testen van de codekwaliteit scant de broncode om ervoor te zorgen dat deze aan bepaalde kwaliteitscriteria voldoet. Dit wordt geïmplementeerd door een combinatie van SonarQube en inhoudspakketonderzoek met behulp van OakPAL. Er zijn meer dan 100 regels, die generieke regels van Java en AEM-specifieke regels combineren. Sommige van de AEM-specifieke regels worden gecreeerd gebaseerd op beste praktijken van AEM Techniek en worden bedoeld als de kwaliteitsregels van de douanecode.
Waarderingen met drie lagen three-tiered-gate
Kwesties die door code kwaliteitstests worden geïdentificeerd worden toegewezen aan één van drie categorieën.
-
Kritiek - dit zijn kwesties die een directe mislukking van de pijpleiding veroorzaken.
-
Belangrijk - dit zijn kwesties die de pijpleiding veroorzaken om een gepauzeerde staat in te gaan. Een plaatsingsmanager, projectmanager, of bedrijfseigenaar kunnen of de kwesties met voeten treden, waarin de pijpleiding te werk gaat, of zij kunnen de kwesties goedkeuren, in welk geval de pijpleiding met een mislukking stopt.
-
Info - dit zijn kwesties die puur voor informatiedoeleinden worden verstrekt en geen effect op de pijpleidingsuitvoering hebben
Waarderingen ratings
De resultaten van deze stap worden geleverd als Waarderingen.
De volgende tabel geeft een overzicht van de classificaties en foutdrempels voor elk van de kritieke, belangrijke en informatiecategorieën.
B = minstens 1 minder kleine kwetsbaarheid
C = minstens 1 belangrijke kwetsbaarheid
D = minstens 1 kritieke kwetsbaarheid
E = minstens 1 kwetsbaarheid van de blocker
B = minstens 1 minder kleine insect
C = minstens 1 belangrijke insect
D = minstens 1 kritieke insect
E = minstens 1 blocker insect
Gedefinieerd door de openstaande herstelkosten voor code ruikt als een percentage van de tijd dat al naar de toepassing is gegaan
- A = <=5%
- B = 6-10%
- C = 11-20%
- D = 21-50%
- E = >50%
Gedefinieerd door een combinatie van de dekking van de testlijn en de voorwaarde met de volgende formule:Coverage = (CT + CF + LC)/(2*B + EL)
CT= Voorwaarden die ten minste één keer alstruezijn geëvalueerd tijdens het uitvoeren van eenheidstestsCF= Voorwaarden die ten minste één keer alsfalsezijn geëvalueerd tijdens het uitvoeren van eenheidstestsLC= Covered lines = lines_to_cover - uncover_linesB= totaal aantal voorwaardenEL= totaal aantal uitvoerbare regels (lines_to_cover)
Gedefinieerd als het aantal regels dat is betrokken bij gedupliceerde blokken. Een codeblok wordt als gedupliceerd beschouwd onder de volgende omstandigheden.
niet-Java Projecten:
- Er moeten ten minste 100 opeenvolgende en gedupliceerde tokens zijn.
- Deze tokens moeten ten minste worden verspreid over:
- 30 regels code voor COBOL
- 20 coderegels voor ABAP
- 10 coderegels voor andere talen
Java-projecten:
- Er moeten minstens tien opeenvolgende en gedupliceerde instructies zijn, ongeacht het aantal tokens en regels.
Verschillen in inspringing en in letterlijke tekenreeksen worden genegeerd wanneer duplicaten worden gedetecteerd.
Werken met valse positieven dealing-with-false-positives
Het kwaliteitscontroleproces is niet perfect en zal soms ten onrechte problemen identificeren die eigenlijk niet problematisch zijn. Dit wordt bedoeld als a vals positief.
In deze gevallen kan de broncode worden geannoteerd met de standaard Java @SuppressWarnings -annotatie die de regel-id opgeeft als het annotatiekenmerk. Bijvoorbeeld, één gemeenschappelijk vals positief is dat de regel SonarQube om hardcoded wachtwoorden te ontdekken agressief kan zijn over hoe een hard - gecodeerd wachtwoord wordt geïdentificeerd.
De volgende code is vrij gemeenschappelijk in een AEM project, dat code heeft om met één of andere externe dienst te verbinden.
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";
SonarQube zal dan een blokkeerkwetsbaarheid veroorzaken. Maar na het herzien van de code, erkent u dat dit geen kwetsbaarheid is en kan de code met aangewezen regelidentiteitskaart annoteren.
@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";
Maar als de code eigenlijk dit was:
@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";
Dan is de correcte oplossing het hardcoded wachtwoord te verwijderen.
@SuppressWarnings -annotatie zo specifiek mogelijk te maken, dat wil zeggen alleen de specifieke instructie of het specifieke blok dat de uitgave veroorzaakt, van annotatie te voorzien op klasseniveau.Optimalisatie van inhoudspakketscannen content-package-scanning-optimization
In het kader van het kwaliteitsanalyseproces voert Cloud Manager een analyse uit van de inhoudspakketten die door de Maven-build worden geproduceerd. Cloud Manager biedt optimalisaties om dit proces te versnellen, die effectief zijn wanneer bepaalde verpakkingsbeperkingen worden nageleefd. Het meest significant is de optimalisering die voor projecten wordt uitgevoerd die één enkel inhoudspakket uitvoeren, dat algemeen als "allen"pakket wordt bedoeld, dat verscheidene andere inhoudspakketten bevat die door de bouwstijl worden geproduceerd, die als overgeslagen worden gemerkt. Wanneer Cloud Manager dit scenario detecteert in plaats van het "all"-pakket uit te pakken, worden de afzonderlijke inhoudspakketten direct gescand en gesorteerd op basis van afhankelijkheden. Neem bijvoorbeeld de volgende build-uitvoer.
all/myco-all-1.0.0-SNAPSHOT.zip(content-package)ui.apps/myco-ui.apps-1.0.0-SNAPSHOT.zip(overgeslagen-content-package)ui.content/myco-ui.content-1.0.0-SNAPSHOT.zip(overgeslagen-content-package)
Als de enige items binnen myco-all-1.0.0-SNAPSHOT.zip de twee overgeslagen inhoudspakketten zijn, worden de twee ingesloten pakketten gescand in plaats van het "all"-inhoudspakket.
Voor projecten die tientallen ingebedde pakketten produceren, is deze optimalisering getoond om naar boven van 10 minuten per pijpleidingsuitvoering te besparen.
Een speciaal geval kan voorkomen wanneer het "alle"inhoudspakket een combinatie overgeslagen inhoudspakketten en bundels OSGi bevat. Als myco-all-1.0.0-SNAPSHOT.zip bijvoorbeeld de twee eerder vermelde ingesloten pakketten en een of meer OSGi-pakketten bevat, wordt een nieuw, minimaal inhoudspakket samengesteld met alleen de OSGi-bundels. Dit pakket krijgt altijd de naam cloudmanager-synthetic-jar-package en de opgenomen bundels worden in /apps/cloudmanager-synthetic-installer/install geplaatst.
- Deze optimalisatie heeft geen invloed op de pakketten die worden geïmplementeerd op AEM.
- Omdat de overeenkomst tussen de ingesloten inhoudspakketten en de overgeslagen inhoudspakketten is gebaseerd op bestandsnamen, kan deze optimalisatie niet worden uitgevoerd als meerdere overgeslagen inhoudspakketten exact dezelfde bestandsnaam hebben of als de bestandsnaam tijdens het insluiten is gewijzigd.