Esempio di pipeline Java
Descrizione dell'immagine cicd-process-pipeline.png
L'orchestratore pipeline guida il processo di pipeline in questo esempio di pipeline Java illustrato utilizzando alcuni strumenti comunemente utilizzati. Di seguito sono riportati i passi del processo.
- Codice modifica
Esegue i controlli Git di base per le credenziali utilizzando Static Application Security Testing (SAST) e avvia la pipeline. Utilizza l'approccio Gitflow per gestire il repository di codici in base alla struttura del codice mediante strumenti quali GitLab o GithHub. Il codice può essere strutturato in modo da avere diramazione, unione e rilascio delle versioni per controllare le modifiche all'origine. Il codice viene mappato ad ambienti quali sviluppo, test, preproduzione e produzione. I commit nelle diverse parti del repository attivano le azioni Sast.
- Ad esempio, GitHub incorpora la scansione statica della sicurezza per cercare i pattern che riconosceranno password e token all'interno del codice e dei file di configurazione.
- Codice generazione
Genera un file JAR/WAR/EAR ed esegue il pull delle dipendenze richieste. Puoi utilizzare strumenti quali Java Apache Maven per compilare e creare il file JAR (o i file di archivio distribuibili correlati) e firmare l'artifact.
- Gestire le dipendenze di terze parti: gestisce le dipendenze di codice e le librerie di terze parti utilizzando strumenti come Snyk. Synk controlla e garantisce che le dipendenze siano corrette, da un'origine accettata, e cerca contenuti dannosi. Recupera, ispeziona, approva e memorizza gli artifact delle dipendenze esterne. La gestione delle dipendenze di terze parti consente di memorizzare le nostre dipendenze in locale utilizzando strumenti quali Archiva, Nexus OSS e così via. È inoltre possibile controllare le dipendenze per assicurarsi che abbiano origini attendibili. Ciò può garantire che la dipendenza non sia stata compromessa con contenuti dannosi utilizzando strumenti come Snyk, Nexus o scanOS.
- Controlla qualità e conformità
Scansione per OWASP Primi 10 problemi e verifica la conformità agli standard di codifica utilizzando strumenti come Sonarcube o Lint.
- Esegui test unità
Esegui test delle unità e acquisisci dati sulla copertura del codice utilizzando JACOCO e JUnit. JACOCO fornisce la raccolta di copertura, ad esempio cerca quali linee di codice sono state eseguite e quanta parte del codice è stata testata in modo statistico. JUnit esegue i test di unità. È possibile scegliere di espandere la descrizione se si ritiene utile.
- Esegui test API
Esegue il test delle API con dati aggiornati e client di test utilizzando strumenti quali Dredd, Apiary o Swagger Hub.
- Test componenti e UX
Testare i componenti del riquadro nero e qualsiasi elemento dell'interfaccia utente. Misura le prestazioni per garantire che non vi siano problemi di base. Raccoglie le metriche di copertura dei test utilizzando strumenti quali Selenium e JMeter. JMeter esegue test della user experience e delle performance e verifica i flussi di lavoro degli utenti. Selenium guida l'esercizio degli elementi dell'interfaccia utente.
- Sicurezza test
Test di codice per vulnerabilità come, ad esempio, il modo in cui gestisce le chiamate API illegali, i payload in eccesso, gli attacchi di iniezione e così via utilizzando Zap. Esegui test di sicurezza controllando la presenza di codice ridondante e istruzioni SQL preparate.
- Package per distribuzione
Raggruppa la soluzione come container, convalida i package e verifica la presenza di problemi e best practice relative ai container utilizzando strumenti come Docker Snyk.
- Genera documentazione
Generare documentazione utile e renderla disponibile per l'utilizzo. Firma gli artefatti utilizzando strumenti come Pandoc o Doxygen. Pandoc passa il progetto alla fase successiva e lo aggiunge all'archivio attendibile, ad esempio un registro, da utilizzare nella fase successiva.
Se uno di questi passi non riesce o il processo identifica troppe avvertenze, la build non riesce. Le build possono avere esito negativo in qualsiasi punto del processo e impedire che i passi successivi continuino. Una build non riuscita impedisce la creazione di promozioni del codice automatizzate configurate. È possibile utilizzare alcuni degli strumenti consigliati per le build con più fasi per supportare l'esecuzione dei test in ciascuna fase. Ad esempio, i test a livello di sistema possono utilizzare strumenti di test API per interagire con il sistema come servizio esterno anziché simulare le azioni di un altro componente all'interno della soluzione aziendale.