Scopri come funziona il test della qualità del codice delle pipeline e come può migliorare la qualità delle distribuzioni.
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.
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.
Scaricare l’elenco completo delle regole con questo collegamento.
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
In una pipeline di sola qualità del codice, non è possibile ignorare importanti errori nel gate Code Quality perché il passaggio di test della qualità del codice è l’ultimo passaggio della pipeline.
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.
Nome | Definizione | Categoria | Soglia errore |
---|---|---|---|
Valutazione della sicurezza | A = Nessuna vulnerabilità B = Almeno 1 vulnerabilità minore C = Almeno 1 vulnerabilità principale D = Almeno 1 vulnerabilità critica E = Almeno 1 vulnerabilità di blocco |
Critico | < B |
Valutazione dell'affidabilità | A = Nessun bug B = almeno 1 bug minore C = almeno 1 bug principale D = Almeno 1 bug critico E = almeno 1 bug di blocco |
Critico | < D |
Valutazione della manutenzione | Definito dal costo residuo di bonifica per il codice, espresso in percentuale del tempo che è già passato nell'applicazione
|
Importante | < A |
Copertura | Definito da una combinazione di copertura della linea di prova di unità e copertura delle condizioni utilizzando la formula: Coverage = (CT + CF + LC)/(2*B + EL)
|
Importante | < 50% |
Test di unità ignorati | Numero di prove di unità saltate | Info | > 1 |
Problemi aperti | Tipi di problemi generali - Vulnerabilità, Bug e Odori di Codice | Info | > 0 |
Linee duplicate | Definito come il numero di righe coinvolte nei blocchi duplicati. Un blocco di codice viene considerato duplicato nelle seguenti condizioni. Progetti non Java:
|
Info | > 1% |
Compatibilità Cloud Service | Numero di problemi di compatibilità del servizio cloud identificati | Info | > 0 |
Fai riferimento a Definizioni delle metriche di SonarQube definizioni più dettagliate.
Per ulteriori informazioni sulle regole di qualità del codice personalizzato eseguite da Cloud Manager, consultare il documento Regole per la qualità del codice personalizzato.
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.
Anche se è una best practice fare @SuppressWarnings
annotazione il più possibile specifica, ovvero annotare solo l’istruzione o il blocco specifici che causano il problema, è possibile annotare a livello di classe.
Anche se non esiste un passaggio esplicito di test della sicurezza, durante il passaggio sulla qualità del codice sono state valutate le regole di qualità del codice relative alla sicurezza. Consulta il documento Panoramica sulla sicurezza per AEM as a Cloud Service per ulteriori informazioni sulla sicurezza in Cloud Service.
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
.