Test di qualità del codice

Il testing della qualità del codice valuta la qualità del codice dell’applicazione. Si tratta dell’obiettivo principale di una pipeline di sola qualità del codice e viene eseguita immediatamente dopo la fase di compilazione in tutte le pipeline non di produzione e produzione.

Per ulteriori informazioni sui diversi tipi di pipeline, consulta Configurazione della pipeline CI-CD .

Regole per la qualità del codice

Nel testing della qualità del codice, il codice sorgente viene analizzato per garantire che soddisfi alcuni criteri di qualità. Attualmente, questo è implementato da una combinazione di SonarQube e l'esame a livello di pacchetto di contenuti utilizzando 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.

Cancello a tre livelli

In questa fase di test della qualità del codice è presente una struttura a tre livelli per i problemi identificati:

• Critico: Si tratta di problemi identificati dal gate che causano un errore immediato della pipeline.

• Importante: Questi sono problemi identificati dal gate 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.

• Informazioni: Si tratta di questioni individuate dal cancello che sono fornite a scopo puramente informativo e non hanno alcun impatto sull’esecuzione 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:

Gestione dei falsi positivi

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

In questi casi, il codice sorgente può essere annotato con l’annotazione Java standard @SuppressWarnings che specifica l’ID regola come attributo dell’annotazione. Ad esempio, un problema comune è che la regola SonarQube per rilevare le password codificate può essere aggressiva riguardo a come 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à quindi una vulnerabilità di blocco. Dopo aver esaminato il codice, identifichi che questa non è una vulnerabilità e puoi annotarla 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.