Test della qualità del codice

Scopri come funziona il test della qualità del codice delle pipeline e come può migliorare la qualità delle distribuzioni.

Introduzione

Il test della qualità del codice valuta il codice dell’applicazione in base a un set di regole di qualità. È lo scopo principale di una pipeline di sola qualità del codice e viene eseguita immediatamente dopo la fase di compilazione in tutte le pipeline di produzione e non di produzione.

Consulta il documento Configurazione della pipeline CI-CD per ulteriori informazioni sui diversi tipi di gasdotti.

Regole per la qualità del codice

Il test di qualità del codice esegue la scansione del codice sorgente per garantire che soddisfi determinati criteri di qualità. Questa funzione è implementata tramite una combinazione di SonarQube e un esame a livello di pacchetto dei contenuti tramite OakPAL. Ci sono più di 100 regole, che combinano regole Java generiche e regole specifiche per AEM. Alcune delle regole specifiche AEM vengono create in base alle best practice di AEM Engineering e sono denominate regole per la qualità del codice personalizzato.

Valutazioni a tre livelli

I problemi identificati dai test di qualità del codice sono assegnati a una delle tre categorie.

• Critico - Si tratta di questioni che causano un immediato fallimento del gasdotto.

• Importante - Si tratta di problemi che fanno sì che la pipeline entri in uno stato di pausa. Un manager distribuzione, un project manager o un proprietario business possono ignorare i problemi, nel qual caso la pipeline procede, oppure possono accettare i problemi, nel qual caso la pipeline si interrompe con un errore.

• Info - Si tratta di questioni che vengono fornite a scopo puramente informativo e che non hanno alcun impatto sull’esecuzione della conduttura

Valutazioni

I risultati di questo passaggio vengono consegnati come Valutazioni.

Nella tabella seguente sono riepilogati i rating e le soglie di errore per ciascuna categoria critica, importante e informativa.

Gestione dei falsi positivi

Il processo di scansione della qualità non è perfetto e talvolta identificherà erroneamente problemi che non sono effettivamente problematici. Questo è indicato come falso positivo.

In questi casi, il codice sorgente può essere annotato con Java standard @SuppressWarnings annotazione che specifica l’ID della regola come attributo di annotazione. Ad esempio, un falso positivo comune è che la regola SonarQube per rilevare le password codificate può essere aggressiva riguardo al modo in cui viene identificata una password hardcoded.

Il codice seguente è abbastanza comune in un progetto AEM, con codice per la connessione a un servizio esterno.

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

SonarQube solleverà quindi una vulnerabilità di blocco. Ma dopo aver esaminato il codice, riconosci che questa non è una vulnerabilità e puoi annotare il codice con l'ID regola appropriato.

@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

Tuttavia, se il codice era effettivamente questo:

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

Quindi la soluzione corretta è quella di rimuovere la password hardcoded.

Ottimizzazione della scansione dei pacchetti di contenuti

Come parte del processo di analisi della qualità, Cloud Manager esegue l’analisi dei pacchetti di contenuto prodotti dalla build Maven. Cloud Manager offre ottimizzazioni per accelerare questo processo, che sono efficaci quando vengono osservati determinati vincoli di imballaggio. La più significativa è l’ottimizzazione eseguita per i progetti che producono un singolo pacchetto di contenuti, generalmente denominato pacchetto "all", che contiene una serie di altri pacchetti di contenuti prodotti dalla build, contrassegnati come saltati. Quando Cloud Manager rileva questo scenario, anziché decomprimere il pacchetto "all", i singoli pacchetti di contenuto vengono analizzati direttamente e ordinati in base alle dipendenze. Ad esempio, considera 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 (saltato-contenuto-pacchetto)
• ui.content/myco-ui.content-1.0.0-SNAPSHOT.zip (saltato-contenuto-pacchetto)

Se gli unici elementi all'interno myco-all-1.0.0-SNAPSHOT.zip sono i due pacchetti di contenuto saltato, quindi i due pacchetti incorporati verranno analizzati al posto del pacchetto di contenuto "all".

Per i progetti che producono decine di pacchetti incorporati, questa ottimizzazione è stata mostrata in modo da risparmiare fino a 10 minuti per esecuzione della pipeline.

Un caso speciale può verificarsi quando il pacchetto di contenuti "all" contiene una combinazione di pacchetti di contenuti saltati e bundle OSGi. Ad esempio, se myco-all-1.0.0-SNAPSHOT.zip conteneva i due pacchetti incorporati precedentemente menzionati e uno o più bundle OSGi, quindi viene costruito un nuovo pacchetto di contenuti minimali con solo i bundle OSGi. Questo pacchetto viene sempre denominato cloudmanager-synthetic-jar-package e i bundle contenuti sono inseriti /apps/cloudmanager-synthetic-installer/install.

Risorse Business.Adobe.com