Test della qualità del codice code-quality-testing

Scopri come funziona il test di 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 il documento 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. Esistono più di 100 regole, che combinano regole Java generiche e regole specifiche per l’AEM. Alcune regole specifiche per AEM si basano sulle best practice indicate dal team ingegneristico dell'AEM e sono note come regole per la qualità del codice personalizzato.

È possibile scaricare l'elenco completo corrente 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.

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: problemi critici, importanti e informativi.

Gestione dei falsi positivi dealing-with-false-positives

Il processo di controllo qualità non è perfetto e talvolta identifica erroneamente problemi che non sono effettivamente problemi. 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. Tra i falsi positivi comuni si annovera ad esempio il caso in cui la regola SonarQube per rilevare le password hardcoded può essere molto rigida riguardo al modo in cui una password hardcoded viene identificata.

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";

Tuttavia, se in realtà il codice era:

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

la soluzione corretta è rimuovere la password hardcoded.

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. Cloud Manager offre ottimizzazioni per accelerare questo processo, che è efficace quando si osservano determinati vincoli relativi ai pacchetti. L’ottimizzazione più significativa riguarda i progetti che producono un singolo pacchetto "all" (tutti), contenente più pacchetti di contenuto della build contrassegnati come ignorati. Quando Cloud Manager rileva questo scenario, anziché decomprimere il pacchetto “all”, scansiona i singoli pacchetti di contenuti e li ordina in base alle dipendenze. Consideriamo ad esempio il seguente output di build.

Se gli unici elementi all’interno di myco-all-1.0.0-SNAPSHOT.zip sono i due pacchetti di contenuto ignorato, allora i due pacchetti incorporati sono analizzati al posto del pacchetto di contenuto “all”.

Per i progetti che producono decine di pacchetti incorporati, è comprovato che questa ottimizzazione consente di risparmiare fino a 10 minuti per ogni 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 contiene i due pacchetti incorporati precedentemente menzionati oltre a uno o più bundle OSGi, allora viene creato un nuovo pacchetto di contenuti minimo con i soli bundle OSGi. Questo pacchetto viene sempre denominato cloudmanager-synthetic-jar-package e i bundle contenuti sono inseriti in /apps/cloudmanager-synthetic-installer/install.