Scopri come funziona il test della qualità del codice delle pipeline e come può migliorare la qualità delle distribuzioni.
Durante l’esecuzione della pipeline, varie metriche vengono acquisite e confrontate con gli indicatori prestazioni chiave (KPI, Key Performance Indicator) definiti dal proprietario business o dagli standard impostati da Adobe Managed Services.
Questi sono segnalati utilizzando un sistema di valutazione a tre livelli.
La pipeline è composta da tre gate:
Per ciascuno di questi gate, esiste una struttura a tre livelli per i problemi identificati dal gate.
In una pipeline di sola qualità del codice, non è possibile ignorare importanti errori nel gate di qualità del codice, poiché il passaggio del test della qualità del codice è l’ultimo passaggio della pipeline.
Questo passaggio valuta la qualità del codice dell’applicazione, che è lo scopo principale di una pipeline di sola qualità del codice, e viene eseguito subito dopo il passaggio di compilazione in tutte le pipeline non di produzione e di produzione. Per ulteriori informazioni, consulta il documento Configurazione delle pipeline di non produzione.
Il test di qualità del codice esegue l’analisi del codice sorgente per garantire che soddisfi determinati criteri di qualità. Questa funzione viene implementata tramite una combinazione di analisi SonarQube, controllo a livello di pacchetto di contenuti tramite OakPAL e convalida del dispatcher tramite lo strumento di ottimizzazione del Dispatcher.
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 di AEM Engineering e sono denominate regole per la qualità del codice personalizzato.
È possibile scaricare l’elenco completo delle regole utilizzando questo collegamento.
I risultati dei test di qualità del codice sono forniti come valutazione, come sintetizzato in questa tabella.
Nome | Definizione | Categoria | Soglia di errore |
---|---|---|---|
Valutazione della sicurezza | A = Nessuna vulnerabilità B = Almeno 1 vulnerabilità minore C = Almeno 1 vulnerabilità grave D = Almeno 1 vulnerabilità critica E = Almeno 1 vulnerabilità bloccante |
Critico | < B |
Valutazione dell’affidabilità | A = Nessun bug B = Almeno 1 bug minore C = Almeno 1 bug grave D = Almeno 1 bug critico E = Almeno 1 bug bloccante |
Importante | < C |
Valutazione della manutenzione | Definito dal costo residuo della correzione dei code smell come percentuale del tempo già trascorso nell’applicazione
|
Importante | < A |
Copertura | Definito da una combinazione di copertura di righe e copertura di condizioni dello unit test utilizzando la formula: Coverage = (CT + CF + LC) / (2 * B + EL)
|
Importante | < 50% |
Unit test ignorati | Numero di unit test ignorati | Info | > 1 |
Problemi aperti | Tipi di problemi generali: vulnerabilità, bug e code smell | Info | > 0 |
Righe duplicate | Definito come il numero di righe presenti in blocchi duplicati. Un blocco di codice si considera duplicato nelle seguenti condizioni. Progetti non Java:
|
Info | > 1% |
Compatibilità Cloud Service | Numero di problemi di compatibilità Cloud Service identificati | Info | > 0 |
Fai riferimento a Definizioni delle metriche di SonarQube per informazioni più dettagliate.
Per ulteriori informazioni sulle regole per la qualità del codice personalizzato eseguite da Cloud Manager, consulta il documento Regole per la qualità del codice personalizzato.
Il processo di analisi della qualità non è perfetto e talvolta identificherà erroneamente problemi che non sono effettivamente tali. Tali problemi sono denominati falsi positivi.
In questi casi, il codice sorgente può essere annotato con annotazione Java standard @SuppressWarnings
che specifica l’ID della regola come attributo di 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 esaminato il codice, riconosci che non si tratta di una vulnerabilità e puoi annotare il codice con l’ID della regola appropriato.
@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";
Tuttavia, se il codice era:
@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";
Quindi la soluzione corretta è quella di rimuovere la password hardcoded.
Anche se è una best practice fare l’annotazione @SuppressWarnings
nel modo più specifico possibile (ad esempio, annotare solo l’istruzione o il blocco specifici che causano il problema), è possibile annotare a livello di classe.
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à.
Nome | Implementazione del controllo di integrità | Categoria |
---|---|---|
La Compatibilità Attach API di firewall deserializzazione è in uno stato accettabile. | Compatibilità Attach Api di firewall deserializzazione | Critico |
Il firewall deserializzazione è funzionale. | Firewall deserializzazione funzionale | Critico |
Il firewall deserializzazione è caricato. | Firewall deserializzazione caricato | Critico |
L’implementazione AuthorizableNodeName non espone l’ID autorizzabile nel nome/percorso del nodo. |
Generazione nome nodo autorizzabile | Critico |
Le password predefinite sono state modificate. | Account di accesso predefiniti | Critico |
Il servlet GET predefinito di Sling è protetto dagli attacchi DOS. | Sling Get Servlet | Critico |
Il gestore Java Script di Sling è configurato in modo appropriato. | Sling Java Script Handler | Critico |
Il gestore di script JSP di Sling è configurato in modo appropriato. | Gestore di script Jsp di Sling | Critico |
SSL è configurato correttamente. | Configurazione SSL | Critico |
Non è stato trovato alcun criterio di profilo utente chiaramente non sicuro. | Accesso predefinito profilo utente | Critico |
Il filtro Referrer Sling è configurato per prevenire attacchi CSRF. | Filtro referrer sling | Importante |
Il manager libreria HTML Adobe Granite è configurato in modo appropriato. | Configurazione manager libreria CQ HTML | Importante |
Il bundle di supporto CRXDE è disabilitato. | Supporto CRXDE | Importante |
Il bundle e il servlet Sling DavEx sono disabilitati. | Verifica stato DavEx | Importante |
Il contenuto di esempio non è installato. | Pacchetti contenuti di esempio | Importante |
Il filtro di richiesta WCM e il filtro di debug WCM sono disabilitati. | Configurazione filtri WCM | Importante |
Il bundle e il servlet Sling WebDAV sono configurati in modo appropriato. | Verifica stato WebDAV | Importante |
Il server Web è configurato per impedire il clickjacking. | Configurazione server Web | Importante |
La replica non sta utilizzando l’utente admin . |
Utenti replica e trasporto | Info |
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.
Il numero di utenti o contenitori virtuali generati da Cloud Manager è determinato dai KPI (tempo di risposta e visualizzazioni pagina/min) definiti dall’utente con il ruolo Proprietario business 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.
Prima dell’inizio del periodo 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.
CM_PERF_TEST_CRAWLER_MAX_PAGES
.
2000
- 7000
.Le pagine sono selezionate da tre set di pagine. Cloud Manager utilizza i registri di accesso dalle istanze AEM in ambienti di produzione e di staging per determinare i seguenti bucket.
Pagine Live popolari: questa opzione è selezionata per assicurarsi che vengano testate le pagine più popolari a cui accedono i clienti live. Cloud Manager legge il registro di accesso e determina le prime 25 pagine più visitate dai clienti live per generare un elenco di Popular Live Pages
principali. L’intersezione di queste che sono presenti anche nell’ambiente di pre-produzione viene quindi sottoposta a ricerca per indicizzazione nell’ambiente di staging.
Altre pagine live: questa opzione viene selezionata per assicurarsi che vengano testate le pagine che non rientrano nelle prime 25 pagine live più popolari, che possono non essere popolari, ma che sono importanti da testare. Simile alle pagine live più popolari, queste vengono estratte dal registro di accesso e devono essere presenti anche nell'ambiente di staging.
Nuove pagine: questa opzione viene selezionata per testare le nuove pagine che possono essere state distribuite solo nell’area di staging non ancora in produzione, ma che è necessario testare.
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:
((200 * 0.5) / 25) * 30 = 120
((200 * 0.5) / 3000) * 30 = 1
Cloud Manager esegue un test delle prestazioni per i programmi 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, ecc.) per ogni pagina e 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.
Metrica | Categoria | Soglia di errore |
---|---|---|
Frequenza di errori di richiesta pagina | Critico | >= 2% |
Frequenza di utilizzo della CPU | Critico | >= 80% |
Tempo di attesa I/O del disco | Critico | >= 50% |
Tempo di risposta del 95° percentile | Importante | >= KPI a livello di programma |
Tempo di risposta al picco | Importante | >= 18 secondi |
Visualizzazioni pagina al minuto | Importante | < KPI a livello di programma |
Utilizzo della larghezza di banda del disco | Importante | >= 90% |
Utilizzo della larghezza di banda di rete | Importante | >= 90% |
Richieste al minuto | Info | >= 6000 |
Consulta la sezione Test delle prestazioni autenticati per ulteriori informazioni sull’utilizzo dell’autenticazione di base per i test delle prestazioni per Sites e Assets.
Durante il periodo di test vengono monitorate sia le istanze di authoring che quelle di pubblicazione. Se non viene ottenuta alcuna metrica per un’istanza, tale metrica viene segnalata come sconosciuta e il passaggio corrispondente non riuscirà.
Se necessario, i clienti AMS con siti autenticati possono 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 deve essere archiviato in una variabile di string
e la password deve essere archiviata in una variabile secretString
. Se vengono specificati entrambi, ogni richiesta del crawler dei test delle prestazioni e degli utenti virtuali del test conterrà queste credenziali come autenticazione HTTP Basic.
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>
Fai riferimento alla documentazione API Variabili della pipeline utente di patch per scoprire come utilizzare l’API.
Cloud Manager esegue test delle prestazioni per i programmi AEM Assets caricando ripetutamente le risorse per un periodo di test di 30 minuti.
Per il test delle prestazioni delle risorse, il CSE (Customer Success Engineer) creerà 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 non deve essere rimosso dall'istanza di authoring né le relative autorizzazioni modificate. Questa operazione potrebbe non riuscire nel test delle prestazioni delle risorse.
I clienti possono caricare le proprie risorse da testare. Questa operazione può essere eseguita 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 utilizzerà un’immagine e un documento PDF predefiniti per il test.
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.
Cloud Manager creerà una cartella sull’istanza di authoring utilizzando il nome utente e la password come configurato 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 nell’arco della durata del test di 30 minuti. Questa funzione consente di caricare sia immagini che documenti PDF.
Fare riferimento al documento Configurare le pipeline di produzione per ulteriori informazioni. Consulta il documento Configurazione del programma per scoprire come impostare il programma e definire i KPI.
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.
Utilizzo CPU: un grafico dell’utilizzo della CPU durante il periodo del test
Tempo di attesa I/O del disco: un grafico del tempo di attesa I/O del disco durante il periodo del test
Frequenza errori pagina: un grafico degli errori di pagina al minuto durante il periodo di test
Utilizzo della larghezza di banda del disco: un grafico dell'utilizzo della larghezza di banda del disco durante il periodo di test
Utilizzo della larghezza di banda di rete: un grafico dell'utilizzo della larghezza di banda di rete durante il periodo di test
Tempo di risposta al picco: un grafico del tempo di risposta di picco al minuto durante il periodo di test
Tempo di risposta del 95° percentile: un grafico del tempo di risposta del 95° percentile al minuto durante il periodo di test
Come parte del processo di analisi della qualità, Cloud Manager esegue l’analisi dei pacchetti di contenuti prodotti dalla build Maven. Per accelerare il processo, Cloud Manager offre delle ottimizzazioni che risultano efficaci quando si osservano determinati vincoli relativi ai pacchetti. La più significativa è l’ottimizzazione dei progetti che producono un singolo pacchetto di contenuti, generalmente denominati pacchetti “all”, che contengono una serie di 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.
all/myco-all-1.0.0-SNAPSHOT.zip
(pacchetto di contenuti)ui.apps/myco-ui.apps-1.0.0-SNAPSHOT.zip
(pacchetto di contenuti ignorato)ui.content/myco-ui.content-1.0.0-SNAPSHOT.zip
(pacchetto di contenuti ignorato)Se gli unici elementi all’interno di myco-all-1.0.0-SNAPSHOT.zip
sono i due pacchetti di contenuti ignorati, al posto del pacchetto “all” verranno analizzati i due pacchetti incorporati.
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
conteneva i due pacchetti incorporati precedentemente menzionati oltre a uno o più bundle OSGi, 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 vengono inseriti in /apps/cloudmanager-synthetic-installer/install
.