Test della qualità del codice code-quality-testing

Scopri come funziona il test della qualità del codice delle pipeline e come può migliorare la qualità delle distribuzioni.

Introduzione introduction

Durante l’esecuzione della pipeline, il software acquisisce una serie di metriche. Queste metriche vengono quindi confrontate con gli indicatori prestazioni chiave (KPI) definiti dal proprietario dell’azienda. Oppure vengono confrontati con gli standard impostati da Adobe Managed Services.

I risultati sono riportati mediante l’utilizzo di un sistema di valutazione a tre livelli.

Valutazioni a tre livelli three-tiered-ratings

La pipeline è composta da tre gate:

Per ciascuno di questi gate, esiste una struttura a tre livelli per i problemi identificati dal gate.

Test della qualità del codice code-quality-testing-step

Questo passaggio di test valuta la qualità del codice dell’applicazione, che è lo scopo principale di una pipeline dedicata esclusivamente alla qualità del codice. Viene eseguito immediatamente dopo la fase di build in tutte le pipeline non di produzione e di produzione. Per ulteriori informazioni, vai alla Configurazione delle pipeline non di produzione.

Il test di qualità del codice esegue la scansione del codice sorgente per garantire che soddisfi determinati criteri di qualità.

Il software lo implementa tramite una combinazione di analisi SonarQube, un controllo a livello di pacchetto di contenuti con OakPAL e una convalida del Dispatcher tramite il relativo strumento di ottimizzazione.

Sono presenti più di 100 regole che combinano regole Java generiche e regole specifiche per AEM. Alcune delle regole specifiche per AEM vengono create in base alle best practice indicate dai tecnici di AEM e sono denominate regole per la qualità del codice personalizzato.

I risultati dei test di qualità del codice sono forniti come valutazione, come sintetizzato in questa tabella.

Gestione dei falsi positivi dealing-with-false-positives

Il processo di scansione della qualità non è perfetto e talvolta identifica erroneamente problemi che in realtà non sono critici. Questo scenario è noto come falso positivo.

In questi casi, il codice sorgente può essere annotato con l’annotazione Java standard @SuppressWarnings che specifica l’ID della regola come attributo dell’annotazione. Tra i falsi positivi comuni si annovera ad esempio il caso in cui la regola SonarQube per rilevare le password hardcoded può essere molto rigida riguardo al modo in cui una password hardcoded viene identificata.

Il codice riportato di seguito è abbastanza comune in un progetto AEM, che presenta un codice per la connessione a un servizio esterno.

@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

SonarQube genera in questo caso una vulnerabilità bloccante. Dopo aver rivisto il codice, riconosci che tale errore non è una vulnerabilità e puoi annotare il codice con l’ID della regola appropriata.

@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

Tuttavia, se in realtà il codice era:

@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";

la soluzione corretta è rimuovere la password hardcoded.

Test di sicurezza security-testing

Cloud Manager esegue le verifiche di integrità e sicurezza AEM esistenti nell’ambiente di staging dopo la distribuzione e segnala lo stato tramite l’interfaccia utente. I risultati vengono aggregati da tutte le istanze AEM nell’ambiente.

Questi stessi controlli di integrità possono essere eseguiti in qualsiasi momento tramite la console web o il dashboard operazioni.

Se una delle istanze segnala un errore per una determinata verifica di integrità, la verifica di integrità dell’intero ambiente non riesce. Come nel caso dei test di qualità e prestazioni del codice, questi controlli di integrità sono organizzati in categorie e segnalati utilizzando il sistema di gating a tre livelli. L’unica distinzione è che non esiste alcuna soglia nel caso di test di sicurezza. Tutti i controlli di integrità sono superati o falliti.

Nella tabella seguente sono elencati i controlli di integrità.

Test delle prestazioni performance-testing

AEM Sites aem-sites

Cloud Manager esegue il test delle prestazioni per i programmi di AEM Sites. Il test delle prestazioni viene eseguito per circa 30 minuti attivando gli utenti virtuali (contenitori) che simulano gli utenti effettivi per accedere alle pagine in ambienti di staging e simulare il traffico. Queste pagine vengono trovate utilizzando un crawler.

Utenti virtuali virtual-users

In Cloud Manager gli utenti o i contenitori virtuali vengono attivati in base ai KPI (tempo di risposta e visualizzazioni pagina/min) impostati dal ruolo Proprietario azienda. Questi KPI vengono impostati durante la creazione o modifica del programma.

In base ai KPI definiti, verranno attivati fino a 10 contenitori che simulano gli utenti effettivi. Le pagine selezionate per il test vengono suddivise e assegnate a ogni utente virtuale.

Crawler crawler

Prima dell’inizio della fase di test di 30 minuti, Cloud Manager eseguirà la ricerca per indicizzazione dell’ambiente di staging utilizzando un set di uno o più URL di seed configurati dal Customer Success Engineer. Partendo da questi URL, l’HTML di ogni pagina viene ispezionato e i collegamenti vengono attraversati in modalità di ampiezza.

Set di pagine per il test page-sets

Tre set di pagine selezionano le pagine. Cloud Manager utilizza i registri di accesso dalle istanze AEM in ambienti di produzione e di staging per determinare i seguenti bucket.

Distribuzione del traffico tra set di pagine selezionati distribution-of-traffic

Puoi scegliere da uno a tutti e tre i set nella scheda Test della configurazione della pipeline. La distribuzione del traffico si basa sul numero di set selezionati. In altre parole, se sono selezionati tutti e tre, il 33% del totale delle visualizzazioni di pagina viene destinato a ogni set. Se ne sono selezionati due, il 50% viene indirizzato a ciascun set. Se ne è selezionato uno, il 100% del traffico viene indirizzato a tale set.

Consideriamo questo esempio.

Nel periodo di test di 30 minuti:

Test e report testing-reporting

Cloud Manager esegue un test delle prestazioni per i programmi di AEM Sites, richiedendo le pagine come utente non autenticato per impostazione predefinita sul server di pubblicazione dello staging per un periodo di test di 30 minuti. Misura le metriche generate dall’utente virtuale (tempo di risposta, tasso di errore, visualizzazioni al minuto e così via) per ogni pagina, nonché varie metriche a livello di sistema (CPU, memoria, dati di rete) per tutte le istanze.

Nella tabella seguente viene riepilogata la matrice dei test di prestazione utilizzando il sistema di verifica a tre livelli.

Consulta Test delle prestazioni autenticati per ulteriori informazioni sull’utilizzo dell’autenticazione di base per i test delle prestazioni relativi a Sites e Assets.

Test delle prestazioni autenticati authenticated-performance-testing

Se necessario,la clientela AMS con siti autenticati può specificare un nome utente e una password che Cloud Manager utilizzerà per accedere al sito web durante il test delle prestazioni dei siti.

Il nome utente e la password sono specificati come variabili della pipeline con i nomi CM_PERF_TEST_BASIC_USERNAME e CM_PERF_TEST_BASIC_PASSWORD.

Il nome utente viene archiviato in una variabile string e la password viene archiviata in una variabile secretString. Se entrambe le variabili vengono specificate, ogni richiesta del crawler dei test delle prestazioni e degli utenti virtuali del test conterrà queste credenziali come autenticazione di base HTTP.

Per impostare queste variabili utilizzando Cloud Manager CLI, esegui:

$ aio cloudmanager:set-pipeline-variables <pipeline id> --variable CM_PERF_TEST_BASIC_USERNAME <username> --secret CM_PERF_TEST_BASIC_PASSWORD <password>

Consulta la documentazione dell’API Variabili della pipeline utente di patch per scoprire come utilizzare l’API.

AEM Assets aem-assets

Cloud Manager esegue il test delle prestazioni per i programmi AEM Assets caricando ripetutamente le risorse per 30 minuti.

Requisito di onboarding onboarding-requirement

Per il test delle prestazioni di Assets, il Customer Success Engineer crea un utente e una password cloudmanager durante l’onboarding dell’authoring nell’ambiente di staging. I passaggi del test delle prestazioni richiedono un utente chiamato cloudmanager e la password associata impostata dal CSE.

Questo metodo deve rimanere nell’istanza di authoring senza modificarne le autorizzazioni. Se lo modifichi o lo rimuovi, il test delle prestazioni di Assets potrebbe non riuscire.

Immagini e Assets da sottoporre a test assets-for-testing

I clienti possono caricare le proprie risorse da sottoporre a test. Questo processo può essere eseguito dalla schermata Configurazione della pipeline o Modifica. Sono supportati formati immagine comuni come JPEG, PNG, GIF e BMP insieme ai file Photoshop, Illustrator e Postscript.

Se non viene caricata alcuna immagine, Cloud Manager utilizza un’immagine e documenti PDF predefiniti per il test.

Distribuzione di risorse da sottoporre a test distribution-of-assets

La distribuzione del numero di risorse di ciascun tipo caricate al minuto è impostata nella schermata Configurazione della pipeline o Modifica.

Ad esempio, se utilizzi una suddivisione 70/30 e sono presenti 10 risorse caricate al minuto, verranno caricate 7 immagini e 3 documenti al minuto.

Test e report testing-and-reporting

Cloud Manager crea una cartella sull’istanza di authoring utilizzando il nome utente e la password configurati dal CSE. Le risorse vengono quindi caricate nella cartella utilizzando una libreria open-source. I test eseguiti dal passaggio di test delle risorse vengono scritti utilizzando una libreria open source. Il tempo di elaborazione di ciascuna risorsa e di varie metriche a livello di sistema vengono misurati durante la durata del test di 30 minuti. Questa funzione consente di caricare sia immagini che documenti PDF.

Grafici dei risultati del test delle prestazioni performance-testing-results-graphs

Sono disponibili diverse metriche nella Finestra di dialogo Test delle prestazioni.

I pannelli delle metriche possono essere espansi per visualizzare un grafico, fornire un collegamento a un download o entrambi.

Questa funzionalità è disponibile per le metriche seguenti.

Ottimizzazione dell’analisi del pacchetto di contenuti content-package-scanning-optimization

Come parte del processo di analisi della qualità, Cloud Manager esegue l’analisi dei pacchetti di contenuti prodotti dalla versione Maven. Per accelerare questo processo, Cloud Manager offre delle ottimizzazioni che risultano efficaci quando si osservano determinati vincoli per la creazione dei pacchetti.

La chiave per l’ottimizzazione è per i progetti che producono un singolo pacchetto “all”, contenente altri pacchetti di contenuti prodotti dalla build e contrassegnati come ignorati. Quando Cloud Manager rileva questo scenario, anziché decomprimere il pacchetto “all”, scansiona i singoli pacchetti di contenuti e li ordina in base alle dipendenze. Consideriamo ad esempio il seguente output di build.

Se gli unici elementi all’interno di myco-all-1.0.0-SNAPSHOT.zip sono i due pacchetti di contenuto ignorato, allora i due pacchetti incorporati sono analizzati al posto del pacchetto di contenuto “all”.

Per i progetti che producono decine di pacchetti incorporati, è comprovato che questa ottimizzazione consente di risparmiare fino a 10 minuti per ogni esecuzione della pipeline.

Un caso speciale può verificarsi quando il pacchetto di contenuti “all” include una combinazione di pacchetti di contenuti e bundle OSGi ignorati. Ad esempio, se myco-all-1.0.0-SNAPSHOT.zip contiene i due pacchetti incorporati precedentemente menzionati oltre a uno o più bundle OSGi, allora viene creato un nuovo pacchetto di contenuti minimo con i soli bundle OSGi. Questo pacchetto viene sempre denominato cloudmanager-synthetic-jar-package e i bundle contenuti sono inseriti in /apps/cloudmanager-synthetic-installer/install.