Verifica della qualità del codice

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.

Informazioni sulle regole di qualità del codice

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.

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:

Gestione dei falsi positivi

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.