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.

NOTA

È 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 è:
  • <>
  • tra il 6 e il 10% il rating è a B
  • tra l'11% e il 20% il rating è a C
  • tra il 21% e il 50% la valutazione è una D
  • un valore superiore al 50% è un E
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:
  • Progetti non Java:
  • Devono essere presenti almeno 100 token successivi e duplicati.
  • Tali token devono essere ripartiti almeno su:
  • 30 righe di codice per COBOL
  • 20 righe di codice per ABAP
  • 10 righe di codice per altre lingue
  • Progetti Java:
  • Devono essere presenti almeno 10 istruzioni successive e duplicate, indipendentemente dal numero di token e di righe.

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
NOTA

Per ulteriori informazioni, fare riferimento a Definizione delle metriche.

NOTA

Per ulteriori informazioni sulle regole di qualità del codice personalizzate eseguite da Cloud Manager, fare riferimento a Custom Code Quality Rules.

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.

NOTA

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.

NOTA

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.

In questa pagina