Test della qualità del codice code-quality-testing
Scopri come funziona il test della qualità del codice delle pipeline e come può migliorare la qualità delle distribuzioni.
Introduzione introduction
Il test di qualità del codice valuta il codice dell’applicazione in base a un set di regole relative alla qualità. È lo scopo principale di una pipeline destinata solo alla qualità del codice e viene eseguito immediatamente dopo la fase di build in tutte le pipeline di produzione e non di produzione.
Per ulteriori informazioni sui diversi tipi di pipeline, consulta Configurazione della pipeline CI-CD.
Regole per la qualità del codice understanding-code-quality-rules
Il test di qualità del codice controlla il codice sorgente per garantire che soddisfi determinati criteri di qualità. Questo passaggio è implementato tramite una combinazione di SonarQube e l’esame dei contenuti a livello di pacchetto tramite OakPAL. Sono presenti più di 100 regole, che combinano regole Java generiche e regole specifiche per AEM. Alcune regole specifiche per AEM si basano sulle best practice indicate dal team ingegneristico di AEM e sono note come regole per la qualità del codice personalizzato.
È possibile scaricare l’attuale elenco completo delle regole utilizzando questo collegamento.
Valutazioni a tre livelli three-tiered-gate
I problemi identificati dai test di qualità del codice vengono assegnati a una delle tre categorie.
-
Critico: si tratta di problemi che causano un errore immediato della pipeline.
-
Importante: si tratta di problemi che causano la sospensione dell’esecuzione della pipeline. Un Responsabile dell’implementazione, un Project Manager o un Responsabile business possono ignorare i problemi, consentendo alla pipeline di procedere. In alternativa, possono accettare i problemi, causando l’interruzione della pipeline con un errore.
-
Informazioni - Problemi forniti a scopo puramente informativo e che non hanno alcun impatto sull’esecuzione della pipeline
Valutazioni ratings
I risultati di questo passaggio vengono consegnati come Valutazioni.
Nella tabella seguente sono riepilogate le valutazioni e le soglie di errore per ciascuna categoria critica, importante e informativa.
B = Almeno 1 vulnerabilità minore
C = Almeno 1 vulnerabilità importante
D = Almeno 1 vulnerabilità critica
E = Almeno 1 vulnerabilità bloccante
B = almeno 1 bug minore
C = almeno 1 bug importante
D = Almeno 1 bug critico
E = almeno 1 bug bloccante
Definito dal costo residuo della correzione dei code smell come percentuale del tempo già trascorso nell’applicazione
- A = <= 5%
- B = 6-10%
- C = 11-20%
- D = 21-50%
- E = > 50%
Definito da una combinazione di copertura di righe e copertura di condizioni dello unit test utilizzando la formula:Coverage = (CT + CF + LC)/(2*B + EL)
CT= condizioni già valutate cometruealmeno una volta durante l’esecuzione degli unit testCF= condizioni già valutate comefalsealmeno una volta durante l’esecuzione degli unit testLC= righe coperte = lines_to_cover - uncovered_linesB= numero totale di condizioniEL= numero totale di righe eseguibili (lines_to_cover)
Definito come il numero di righe presenti in blocchi duplicati. Un blocco di codice viene considerato duplicato nelle seguenti condizioni.
Progetti non Java:
- Devono esserci almeno 100 token successivi e duplicati.
- Tali token devono essere distribuiti, per lo meno, come segue:
- 30 righe di codice per COBOL
- 20 righe di codice per ABAP
- 10 righe di codice per altri linguaggi
Progetti Java:
- Devono essere presenti almeno 10 istruzioni successive e duplicate indipendentemente dal numero di token e righe.
Le differenze nel rientro e nelle stringhe letterali vengono ignorate quando si rilevano duplicati.
Gestione dei falsi positivi dealing-with-false-positives
Il processo di analisi della qualità non è privo di errori e talvolta identifica problemi che non sono difetti effettivi. Questo stato è denominato falso positivo.
In questi casi, il codice sorgente può essere annotato con l’annotazione Java standard @SuppressWarnings che specifica l’ID della regola come attributo dell’annotazione. Ad esempio, un falso positivo comune è che la regola SonarQube per rilevare le password hardcoded può essere eccessivamente restrittiva sul modo in cui viene identificata una password hardcoded.
Il codice riportato di seguito è abbastanza comune in un progetto AEM, che presenta un codice per la connessione a un servizio esterno.
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";
SonarQube genera una vulnerabilità di blocco. Dopo aver rivisto il codice, riconosci che tale errore non è una vulnerabilità e puoi annotare il codice con l’ID della regola appropriata.
@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";
Se il codice era il seguente:
@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";
la soluzione corretta è rimuovere la password hardcoded.
@SuppressWarnings, è possibile aggiungere annotazioni anche a livello di classe.Ottimizzazione dell’analisi dei pacchetti di contenuti content-package-scanning-optimization
Come parte del processo di analisi della qualità, Cloud Manager esegue l’analisi dei pacchetti di contenuti prodotti dalla build Maven. Per accelerare questo processo, Cloud Manager offre delle ottimizzazioni che risultano efficaci quando si osservano determinati vincoli per la creazione dei pacchetti. L’ottimizzazione più significativa riguarda i progetti che producono un unico pacchetto “all”. Questo pacchetto contiene più pacchetti di contenuto della build contrassegnati come ignorati. Quando Cloud Manager rileva questo scenario, anziché decomprimere il pacchetto “all”, i singoli pacchetti di contenuti vengono analizzati direttamente e ordinati in base alle dipendenze. Consideriamo ad esempio il seguente output di build.
all/myco-all-1.0.0-SNAPSHOT.zip(pacchetto di contenuti)ui.apps/myco-ui.apps-1.0.0-SNAPSHOT.zip(pacchetto di contenuti ignorato)ui.content/myco-ui.content-1.0.0-SNAPSHOT.zip(pacchetto di contenuti ignorato)
Se gli unici elementi all’interno di myco-all-1.0.0-SNAPSHOT.zip sono i due pacchetti di contenuti ignorati, allora i due pacchetti incorporati sono analizzati al posto del pacchetto di contenuti “all”.
Per i progetti che producono decine di pacchetti incorporati, è stato dimostrato che questa ottimizzazione risparmia più di 10 minuti per esecuzione della pipeline.
Un caso speciale può verificarsi quando il pacchetto di contenuti “all” include una combinazione di pacchetti di contenuti e bundle OSGi ignorati. Ad esempio, se myco-all-1.0.0-SNAPSHOT.zip conteneva i due pacchetti incorporati e i bundle OSGi menzionati, viene creato un nuovo pacchetto di contenuto minimo con solo i bundle OSGi. Questo pacchetto viene sempre denominato cloudmanager-synthetic-jar-package e i bundle contenuti sono inseriti in /apps/cloudmanager-synthetic-installer/install.
- Questa ottimizzazione non influisce sui pacchetti distribuiti in AEM.
- La corrispondenza tra pacchetti di contenuti incorporati e pacchetti di contenuti ignorati si basa sui nomi dei file. Questa ottimizzazione non può verificarsi se più pacchetti ignorati condividono lo stesso nome di file o se il nome di file cambia durante l’incorporamento.