Tutorial sulla consegna continua - Creazione di una pipeline di consegna continua utilizzando Jenkins



Questo blog sulla consegna continua spiegherà ogni singola fase coinvolta in essa, come la costruzione, il test ecc. Con un pratico utilizzo di Jenkins.

Consegna continua:

La consegna continua è un processo in cui le modifiche al codice vengono create, testate e preparate automaticamente per un rilascio alla produzione.Spero ti sia piaciuto il mio Qui parlerò dei seguenti argomenti:

  • Cos'è la consegna continua?
  • Tipi di test del software
  • Differenza tra integrazione, distribuzione e distribuzione continue
  • Qual è la necessità per la consegna continua?
  • Utilizzo pratico di Jenkins e Tomcat

Cerchiamo di capire rapidamente come funziona la consegna continua.





Cos'è la consegna continua?

È un processo in cui si crea il software in modo tale che possa essere rilasciato in produzione in qualsiasi momento.Considera il diagramma seguente:

Consegna continua - Consegna continua - Edureka



Lascia che ti spieghi il diagramma sopra:

  • Gli script di build automatizzati rileveranno le modifiche nella gestione del codice sorgente (SCM) come Git.
  • Una volta rilevata la modifica, il codice sorgente verrà distribuito su un server di compilazione dedicato per assicurarsi che la compilazione non abbia esito negativo e che tutte le classi di test e i test di integrazione funzionino correttamente.
  • Quindi, l'applicazione di compilazione viene distribuita sui server di test (server di pre-produzione) per l'UAT (User Acceptance Test).
  • Infine, l'applicazione viene distribuita manualmente sui server di produzione per il rilascio.

Prima di procedere, sarà giusto che ti spieghi i diversi tipi di test.

Tipi di test del software:

In generale, esistono due tipi di test:



  • Test Blackbox: È una tecnica di test che ignora il meccanismo interno del sistema e si concentra sull'output generato rispetto a qualsiasi input ed esecuzione del sistema. È anche chiamato test funzionale. Fondamentalmente è utilizzato per convalidare il software.
  • Test Whitebox: è una tecnica di test che tiene conto del meccanismo interno di un sistema. È anche chiamato test strutturale e test della scatola di vetro. Fondamentalmente è utilizzato per verificare il software.

Test whitebox:

Esistono due tipi di test che rientrano in questa categoria.

  • Test unitario: È il test di una singola unità o di un gruppo di unità correlate. Viene spesso eseguito dal programmatore per verificare che l'unità che ha implementato stia producendo l'output atteso rispetto a un dato input.
  • Test d'integrazione: È un tipo di test in cui si trova un gruppo di componenticombinato per produrre l'output. Inoltre, l'interazione tra software e hardware viene testata se i componenti software e hardware hanno una relazione. Potrebbe rientrare sia nei test white box che nei test black box.

Test Blackbox:

Esistono più test che rientrano in questa categoria. Mi concentrerò sualcune, che è importante che tu sappia, per capire questo blog:

  • Test funzionali / di accettazione: Assicura che la funzionalità specificata richiesta nei requisiti di sistema funzioni. Viene fatto per assicurarsi che il prodotto consegnato soddisfi i requisiti e funzioni come previsto dal cliente
  • Test di sistema: Assicura che inserendo il software in ambienti diversi (ad es. Sistemi operativi) funzioni ancora.
  • Stress Test: Valuta come si comporta il sistema in condizioni sfavorevoli.
  • Beta test: Viene eseguito dagli utenti finali, da un team esterno allo sviluppo o dal rilascio pubblico della pre-versione completa del prodotto, nota comebetaversione. Lo scopo del beta testing è quello di coprire errori imprevisti.

Ora è il momento giusto per spiegare la differenza tra integrazione continua, consegna e distribuzione.

Differenze tra integrazione continua, consegna e distribuzione:

Il contenuto visivo raggiunge il cervello di un individuo in un modo più veloce e più comprensibile rispetto alle informazioni testuali. Quindi inizierò con un diagramma che spiega chiaramente la differenza:

In Continuous Integration, ogni commit di codice viene compilato e testato, ma non è in condizione di essere rilasciato. Voglio dire che l'applicazione di compilazione non viene distribuita automaticamente sui server di test per convalidarla utilizzando diversi tipi di test Blackbox come - Test di accettazione dell'utente (UAT).

In Continuous Delivery, l'applicazione viene distribuita continuamente sui server di test per UAT. Oppure puoi dire che l'applicazione è pronta per essere rilasciata in produzione in qualsiasi momento. Quindi, ovviamente, l'integrazione continua è necessaria per la consegna continua.

La distribuzione continua è il passaggio successivo alla consegna continua, in cui non stai solo creando un pacchetto distribuibile, ma in realtà lo stai distribuendo in modo automatizzato.

Consentitemi di riassumere le differenze utilizzando una tabella:

Integrazione continua Consegna continua Distribuzione continua
Build automatizzata per ogni impegnoBuild automatizzata e UAT per ogni commitBuild automatizzata, UAT e rilascio in produzione per ogni commit
Indipendente dalla distribuzione continua e dalla distribuzione continuaÈ il passo successivo dopo l'integrazione continuaè un ulteriore passo avanti nella consegna continua
Alla fine, l'applicazione non è in condizione di essere rilasciata in produzioneAlla fine, l'applicazione è in condizione di essere rilasciata alla produzione.L'applicazione viene distribuita continuamente
Include il test WhiteboxInclude i test Blackbox e WhiteboxInclude l'intero processo necessario per distribuire l'applicazione

In termini semplici, l'integrazione continua fa parte sia della distribuzione continua che della distribuzione continua. E la distribuzione continua è come la consegna continua, tranne per il fatto che i rilasci avvengono automaticamente.

Scopri come creare pipeline CI / CD utilizzando Jenkins On Cloud

Ma la domanda è se l'integrazione continua sia sufficiente.

Perché abbiamo bisogno di consegne continue?

Cerchiamo di capirlo con un esempio.

Immagina che ci siano 80 sviluppatori che lavorano su un grande progetto. Stanno usando pipeline di integrazione continua per facilitare le build automatizzate. Sappiamo che la build include anche Unit Testing. Un giorno hanno deciso di distribuire l'ultima build che aveva superato gli unit test in un ambiente di test.

Questo deve essere un approccio lungo ma controllato alla distribuzione che i loro specialisti ambientali hanno eseguito. Tuttavia, il sistema non sembrava funzionare.

Quale potrebbe essere la causa evidente del fallimento?

Bene, la prima ragione per cui la maggior parte delle persone penserà è che c'è qualche problema con la configurazione. Come la maggior parte delle persone, anche loro la pensavano così.Hanno passato molto tempo a cercare di trovare cosa non andava nella configurazione dell'ambiente, ma non sono riusciti a trovare il problema.

Uno sviluppatore perspicace ha adottato un approccio intelligente:

Quindi uno degli sviluppatori senior ha provato l'applicazione sulla sua macchina di sviluppo. Non ha funzionato neanche lì.

Tornò indietro attraverso le versioni precedenti e precedenti finché non scoprì che il sistema aveva smesso di funzionare tre settimane prima. Un bug minuscolo e oscuro aveva impedito al sistema di avviarsi correttamente. Tuttavia, il progetto ha avuto una buona copertura dei test unitari.Nonostante ciò, 80 sviluppatori, che di solito eseguivano solo i test anziché l'applicazione stessa, non hanno visto il problema per tre settimane.

Dichiarazione problema:

Senza eseguire test di accettazione in un ambiente simile alla produzione, non sanno se l'applicazione soddisfa le specifiche del cliente, né se può essere distribuita e sopravvivere nel mondo reale. Se desiderano un feedback tempestivo su questi argomenti, devono estendere la gamma del loro processo di integrazione continua.

cosa sono i filtri di contesto nel tableau

Consentitemi di riassumere le lezioni apprese esaminando i problemi di cui sopra:

  • I test unitari verificano solo la prospettiva di uno sviluppatore della soluzione a un problema. Hanno solo una capacità limitata di dimostrare che l'applicazione fa ciò che dovrebbe dal punto di vista degli utenti. Non bastanoidentificare i veri problemi funzionali.
  • La distribuzione dell'applicazione nell'ambiente di prova è un processo complesso, che richiede molta manualità e che è stato piuttosto soggetto a errori.Ciò significava che ogni tentativo di implementazione era un nuovo esperimento: un processo manuale soggetto a errori.

Soluzione - Pipeline di fornitura continua (test di accettazione automatizzato):

Hanno portato l'integrazione continua (consegna continua) al passaggio successivo e hanno introdotto un paio di test di accettazione semplici e automatizzati che hanno dimostrato che l'applicazione funzionava e poteva svolgere la sua funzione più fondamentale.La maggior parte dei test eseguiti durante la fase del test di accettazione sono test di accettazione funzionale.

Fondamentalmente, hanno costruito una pipeline di consegna continua, al fine di assicurarsi che l'applicazione venga distribuita senza problemi nell'ambiente di produzione, assicurandosi che l'applicazione funzioni correttamente quando viene distribuita sul server di prova che è una replica del server di produzione.

Basta con la teoria, ora ti mostrerò come creare una pipeline di consegna continua utilizzando Jenkins.

Pipeline di consegna continua utilizzando Jenkins:

Qui userò Jenkins per creare una pipeline di consegna continua, che includerà le seguenti attività:

Passaggi coinvolti nella demo:

  • Recupero del codice da GitHub
  • Compilazione del codice sorgente
  • Test di unità e generazione dei rapporti di prova JUnit
  • Comprimere l'applicazione in un file WAR e distribuirla sul server Tomcat

Prerequisiti:

  • CentOS 7 Machine
  • Jenkins 2.121.1
  • Docker
  • Tomcat 7

Passaggio - 1 Compilazione del codice sorgente:

Cominciamo creando prima un progetto Freestyle a Jenkins. Considera lo screenshot qui sotto:

Dai un nome al tuo progetto e seleziona Freestyle Project:

Quando scorri verso il basso troverai un'opzione per aggiungere il repository del codice sorgente, seleziona git e aggiungi l'URL del repository, in quel repository c'è una multa pom.xml che useremo per costruire il nostro progetto. Considera lo screenshot qui sotto:

Ora aggiungeremo un trigger di build. Scegli l'opzione di polling SCM, fondamentalmente configureremo Jenkins per eseguire il polling del repository GitHub ogni 5 minuti per le modifiche nel codice. Considera lo screenshot qui sotto:

Prima di procedere, lascia che ti dia una piccola introduzione al ciclo di compilazione di Maven.

Ciascuno dei cicli di vita di compilazione è definito da un elenco diverso di fasi di compilazione, in cui una fase di compilazione rappresenta una fase del ciclo di vita.

Di seguito è riportato l'elenco delle fasi di costruzione:

  • validate - validate il progetto è corretto e tutte le informazioni necessarie sono disponibili
  • compile - compila il codice sorgente del progetto
  • test: verifica il codice sorgente compilato utilizzando un framework di unit test appropriato. Questi test non dovrebbero richiedere che il codice venga impacchettato o distribuito
  • pacchetto: prendi il codice compilato e crea un pacchetto nel suo formato distribuibile, come un JAR.
  • verifica: esegue qualsiasi controllo sui risultati dei test di integrazione per garantire il rispetto dei criteri di qualità
  • install: installa il pacchetto nel repository locale, da utilizzare come dipendenza in altri progetti in locale
  • deploy: eseguito nell'ambiente di compilazione, copia il pacchetto finale nel repository remoto per condividerlo con altri sviluppatori e progetti.

Posso eseguire il comando seguente, per compilare il codice sorgente, test di unità e persino impacchettare l'applicazione in un file war:

mvn clean package

Puoi anche suddividere il tuo lavoro di costruzione in una serie di passaggi di costruzione. Ciò semplifica l'organizzazione delle build in fasi pulite e separate.

Quindi inizieremo compilando il codice sorgente. Nella scheda build, fai clic su invoca obiettivi maven di primo livello e digita il comando seguente:

compilare

Considera lo screenshot qui sotto:

Questo estrarrà il codice sorgente dal repository GitHub e lo compilerà (fase di compilazione Maven).

Fare clic su Salva ed eseguire il progetto.

Ora, fai clic sull'output della console per vedere il risultato.

Step - 2 Unit Testing:

Ora creeremo un altro progetto Freestyle per i test unitari.

Aggiungi lo stesso URL del repository nella scheda di gestione del codice sorgente, come abbiamo fatto nel lavoro precedente.

Ora, nella scheda 'Buid Trigger' fare clic su 'build after other projects are built'. Lì digita il nome del progetto precedente in cui stiamo compilando il codice sorgente e puoi selezionare una delle seguenti opzioni:

  • Attiva solo se la build è stabile
  • Trigger anche se la build è instabile
  • Trigger anche se la compilazione fallisce

Penso che le opzioni di cui sopra siano abbastanza autoesplicative, quindi selezionane una qualsiasi. Considera lo screenshot qui sotto:

Nella scheda Costruisci, fai clic su richiama bersagli maven di primo livello e usa il comando seguente:

test

Jenkins fa anche un ottimo lavoro nell'aiutarti a visualizzare i risultati dei test e le tendenze dei risultati dei test.

Lo standard de facto per i rapporti di prova nel mondo Java è un formato XML utilizzato da JUnit. Questo formato è utilizzato anche da molti altri strumenti di test Java, come TestNG, Spock e Easyb. Jenkins comprende questo formato, quindi se la tua build produce risultati di test XML JUnit, Jenkins può generare bei rapporti grafici di test e statistiche sui risultati dei test nel tempo e ti consente anche di visualizzare i dettagli di eventuali errori di test. Jenkins tiene anche traccia della durata dei test, sia a livello globale che per test: questo può tornare utile se è necessario individuare problemi di prestazioni.

Quindi la prossima cosa che dobbiamo fare è convincere Jenkins a tenere sotto controllo i nostri test unitari.

Vai alla sezione Azioni post-compilazione e seleziona la casella di controllo 'Pubblica rapporto sui risultati del test JUnit'. Quando Maven esegue gli unit test in un progetto, genera automaticamente i rapporti di test XML in una directory chiamata report sicuri. Quindi inserisci '** / target / surefire-reports / *. Xml' nel campo 'Test report XML'. I due asterischi all'inizio del percorso ('**') sono una best practice per rendere la configurazione un po 'più robusta: consentono a Jenkins di trovare la directory di destinazione indipendentemente da come abbiamo configurato Jenkins per controllare il codice sorgente.

** / target / surefire-reports / *. xml

Salvalo di nuovo e fai clic su Crea ora.

Ora, il rapporto JUnit è scritto in / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behavior.

Nella dashboard di Jenkinspuoi anche notare i risultati del test:

Passaggio 3: creazione di un file WAR e distribuzione sul server Tomcat:

Il passaggio successivo consiste nel creare un pacchetto della nostra applicazione in un file WAR e distribuirlo sul server Tomcat per il test di accettazione dell'utente.

Crea un altro progetto freestyle e aggiungi l'URL del repository del codice sorgente.

Quindi nella scheda trigger di build, seleziona build quando vengono creati altri progetti, considera lo screenshot qui sotto:

Fondamentalmente, dopo il lavoro di prova, la fase di distribuzione inizierà automaticamente.

Nella scheda build, seleziona shell script. Digita il comando seguente per creare il pacchetto dell'applicazione in un file WAR:

pacchetto mvn

Il prossimo passo è distribuire questo file WAR su Tomcatserver. Nella scheda 'Azioni post-build' seleziona distribuisci war / ear in un container. Qui, dai il percorso al file war e dai il percorso del contesto. Considera lo screenshot qui sotto:

Seleziona le credenziali Tomcat e osserva lo screenshot qui sopra. Inoltre, devi fornire l'URL del tuo server Tomcat.

Per aggiungere credenziali in Jenkins, fare clic sull'opzione credenziali nella dashboard di Jenkins.

Fare clic su Sistema e selezionare le credenziali globali.

Quindi troverai un'opzione per aggiungere le credenziali. Fare clic su di esso e aggiungere le credenziali.

Aggiungi le credenziali Tomcat, considera lo screenshot qui sotto.

Fare clic su OK.

Ora nella Configurazione del progetto, aggiungi le credenziali Tomcat che hai inserito nel passaggio precedente.

Fare clic su Salva e quindi selezionare Crea ora.

Vai al tuo URL Tomcat, con il percorso del contesto, nel mio caso è http: // localhost: 8081. Ora aggiungi il percorso del contesto alla fine, considera lo screenshot seguente:

Collegamento: http: // localhost: 8081 / gof

Spero che tu abbia capito il significato del percorso del contesto.

Ora crea una vista pipeline, considera lo screenshot qui sotto:

ordine crescente c ++

Fare clic sull'icona più per creare una nuova visualizzazione.

Configura la pipeline nel modo desiderato, considera lo screenshot qui sotto:

Non ho cambiato nulla a parte la selezione del lavoro iniziale. Quindi la mia pipeline inizierà dalla compilazione. In base al modo in cui ho configurato altri lavori, dopo la compilazione verranno eseguiti i test e la distribuzione.

Infine, puoi testare la pipeline facendo clic su ESEGUI. Dopo ogni cinque minuti, se viene apportata una modifica al codice sorgente, verrà eseguita l'intera pipeline.

Quindi siamo in grado di distribuire continuamente la nostra applicazione sul server di test per il test di accettazione dell'utente (UAT).

Spero che ti sia piaciuto leggere questo post sulla consegna continua. Se hai dei dubbi, sentiti libero di metterli nella sezione commenti qui sotto e ti risponderò con una risposta al più presto.

Per creare pipeline CI / CD è necessario padroneggiare un'ampia varietà di competenze Padroneggia ora le abilità DevOps richieste