Il test della qualità del codice valuta la qualità del codice dell’applicazione. Si tratta dell'obiettivo principale di una conduttura di sola qualità del codice ed è eseguito immediatamente dopo la fase di costruzione in tutti i gasdotti non di produzione e produzione.
Fare riferimento a Configurazione della tubazione CI-CD per ulteriori informazioni sui diversi tipi di tubazioni.
In Test qualità codice, il codice sorgente viene analizzato per garantire che soddisfi determinati criteri di qualità. Attualmente, questo è implementato tramite una combinazione di SonarQube e l'esame a livello di pacchetto di contenuti tramite OakPAL. Ci sono più di 100 regole che combinano regole Java generiche e regole AEM specifiche. Alcune delle regole specifiche AEM vengono create in base alle best practice di AEM Engineering e sono denominate Custom Code Quality Rules.
È possibile scaricare l'elenco completo delle regole qui.
Porta a tre livelli
Esiste una struttura a tre livelli in questa fase di test della qualità del codice per i problemi identificati:
Critico: Si tratta di problemi individuati dal cancello che causano un immediato fallimento della conduttura.
Importante: Si tratta di problemi identificati dal gate che causano l'ingresso della pipeline in stato di pausa. Un gestore di distribuzione, un project manager o un proprietario aziendale 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.
Informazioni: Si tratta di questioni individuate dalla porta che sono fornite esclusivamente a scopo informativo e che non hanno alcun impatto sull'esecuzione della conduttura
I risultati di questo passaggio vengono presentati come Valutazioni.
La tabella seguente riassume le soglie di rating e di fallimento per ciascuna delle categorie Critico, Importante e Informazioni:
Nome | Definizione | Categoria | Soglia di errore |
---|---|---|---|
Valutazione sicurezza | A = 0 Vulnerabilità B = almeno 1 Vulnerabilità minore C = almeno 1 Vulnerabilità maggiore D = almeno 1 Vulnerabilità critica E = almeno 1 Vulnerabilità blocco |
Critico | < B |
Valutazione affidabilità | A = 0 Bug B = almeno 1 Bug Minore C = almeno 1 Bug Principale D = almeno 1 Bug Critico E = almeno 1 Bug Blocco |
Importante | < C |
Classificazione manutenibilità | L'eccezionale costo di riparazione per gli odori di codice è:
|
Importante | < A |
Copertura | Una combinazione di copertura della linea di prova di unità e copertura della condizione utilizzando la seguente formula: Coverage = (CT + CF + LC)/(2*B + EL) dove: CT = condizioni che sono state valutate come 'true' almeno una volta durante l'esecuzione di unit test CF = condizioni che sono state valutate come 'false' almeno una volta durante l'esecuzione di unit test LC = linee coperte = lines_to_cover - uncover_lines B = numero totale di condizioni EL = numero totale di linee eseguibili (lines_to_cover) |
Importante | < 50% |
Test di unità ignorati | Numero di unit test ignorati. | Info | > 1 |
Problemi aperti | Tipi di problemi generali - Vulnerabilità, bug e odori di codice | Informazioni | > 0 |
Linee duplicate | Numero di righe coinvolte in blocchi duplicati. Per considerare un blocco di codice come duplicato:
Le differenze nei rientri e nei letterali di stringa vengono ignorate durante il rilevamento di duplicati. |
Informazioni | > 1% |
Compatibilità Cloud Service | Numero di problemi di compatibilità Cloud Service identificati. | Informazioni | > 0 |
Per ulteriori informazioni, fare riferimento a Definizione delle metriche.
Per ulteriori informazioni sulle regole di qualità del codice personalizzate eseguite da Cloud Manager, fare riferimento a Custom Code Quality Rules.
Il processo di scansione della qualità non è perfetto e a volte identificherà erroneamente i problemi che non sono effettivamente problematici. Questo viene definito come falso positivo.
In questi casi, il codice sorgente può essere annotato con l'annotazione standard Java @SuppressWarnings
che specifica l'ID regola come attributo annotazione. Ad esempio, un problema comune è che la regola SonarQube per rilevare le password hardcoded può essere aggressiva per quanto riguarda il modo in cui viene identificata una password hardcoded.
Per osservare un esempio specifico, questo codice è 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à una vulnerabilità di blocco. Dopo aver rivisto il codice, identificate che non si tratta di una vulnerabilità e potete annotarlo con l'ID regola appropriato.
@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";
Tuttavia, se il codice fosse effettivamente questo:
@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";
Quindi la soluzione corretta è rimuovere la password hardcoded.
Sebbene sia buona norma rendere l'annotazione @SuppressWarnings
il più specifica possibile, ovvero annotare solo l'istruzione o il blocco specifico che causa il problema, è possibile inserire delle annotazioni a livello di classe.
Anche se non è presente un passaggio esplicito di verifica della sicurezza, durante il passaggio della qualità del codice sono ancora presenti regole di qualità del codice relative alla sicurezza valutate. Fare riferimento a Panoramica sulla protezione per AEM come Cloud Service per ulteriori informazioni sulla protezione in Cloud Service.