Menu

Integrazione continua in DevOps

continuous integration devops

Prova Il Nostro Strumento Per Eliminare I Problemi

Cos'è l'integrazione continua in DevOps?

Finora abbiamo trattato la Parte 1 e la Parte 2 di questo argomento nelle nostre sessioni precedenti e attualmente nella Parte 3.

il miglior downloader di mp3 per Android

Fino alla parte 2, abbiamo trattato l'aspetto delle persone e dei processi di DevOps, che è la collaborazione e il focus sull'obiettivo comune, la mentalità comune e il pensiero comune nel team che aiuta a raggiungere gli obiettivi di DevOps.

Integrazione continua in devlops

Nel nostro ultimo tutorial, abbiamo acquisito conoscenza su Come sviluppare la collaborazione in DevOps .

Controlla => Guida definitiva su DevOps

Continuous Integration, Continuous Testing, Continuous Deployment e Continuous Delivery sono i principali aspetti tecnici di DevOps.

VIDEO Parte 3 Blocco 1: integrazione continua- 12 minuti e 20 secondi

Trascrizione:

Nell'ultimoparte, abbiamo appreso le pratiche di DevOps in base alle quali abbiamo appreso quali parti dei principi agili sono adottate dalle pratiche DevOps.

Come vengono raggiunti gli obiettivi di DevOps attraverso questi principi?

Abbiamo studiato l'importanza del controllo della versione, dell'automazione e della fornitura di piccoli incrementi di valore ai clienti e dei relativi vantaggi.

Che cos'è la collaborazione nel contesto di DevOps e come la realizziamo?

Finora abbiamo parlato degli aspetti relativi alle persone e ai processi di DevOps, ovvero collaborazione e focalizzazione su un obiettivo comune e una mentalità comune e un pensiero comune all'interno del team che aiuta a raggiungere gli obiettivi di DevOps, ora impariamo alcuni aspetti tecnici di DevOps , che rende possibile una versione DevOps.

Sono integrazione continua, distribuzione e distribuzione continue e test continui.

Come parte del blocco 1 della parte 3, studiamo prima 'Integrazione continua'.

Cos'è l'integrazione continua?

Integrazione continua -> CI -> set di processi -> Build pipeline / CI Pipeline

L'integrazione continua, brevemente chiamata 'CI' in DevOps, è un processo importante o un insieme di processi che viene definito ed eseguito come parte di una pipeline chiamata 'Build Pipeline' o 'CI Pipeline'.

Sappiamo che nella pratica DevOps abbiamo un unico strumento di controllo della versione sia per il team di sviluppo che per quello operativo, in cui il codice di tutti verrà depositato come base di codice principale e questo consente al team di lavorare in parallelo.

Quindi, l'integrazione continua, in DevOps, non è altro che unire il codice dei singoli sviluppatori nella copia principale del codice nel ramo principale dove viene mantenuto il controllo della versione. Non ci sono restrizioni sul numero di volte per l'unione del codice che deve avvenire in un giorno.

Ogni volta che lo sviluppatore effettua il check-in del proprio codice nel controllo della versione, inizia immediatamente il processo di avvio CI.

come inserire codice in un sito web

Il processo CI include,

  1. Unione di tutto il codice degli sviluppatori nella riga principale,
  2. Attivare una build,
  3. Compilare il codice e fare una build e ... infine
  4. Esecuzione dello unit test.

Pertanto, l'integrazione continua è un processo di fusione di tutto il codice dello sviluppatore in una posizione centrale e di convalida di ciascuna delle loro unioni con una compilazione e un test automatizzati.

Per spiegare tecnicamente cosa succede durante CI è,

Ci sarà un server per l'integrazione continua che ospita il file Strumento CI , che continua a monitorare lo strumento di controllo della versione per il check-in del codice e non appena viene trovato un check-in, attiva la compilazione automatizzata, crea ed esegue unit test insieme all'analisi statica del codice e un livello base di test di sicurezza automatizzati .

I vari strumenti per eseguire i test automatizzati, come Jenkins, TestNG, NUnit per eseguire test unitari, Sonar per eseguire analisi statiche del codice e fortificare per eseguire i test di sicurezza, tutti questi strumenti saranno integrati con la pipeline CI .

Pertanto, l'intera pipeline CI è un processo automatizzato senza alcun intervento manuale e viene eseguito in pochi secondi o minuti.

Quindi, il principale vantaggio dell'IC è il rapido feedback che gli sviluppatori ottengono in pochissimo tempo.

  1. L'elemento della configurazione viene eseguito dopo che lo sviluppatore ha archiviato il codice e restituito i risultati in pochi secondi. Quindi, consente agli sviluppatori di sapere immediatamente se il loro codice è stato costruito o rotto con successo.
  2. Inoltre, consente allo sviluppatore di sapere se il suo codice si è integrato con successo con il codice dell'altro o si è rotto, qualcosa che un altro membro del team ha fatto in una parte diversa della base di codice. Quindi, CI esegue l'analisi del codice più rapida e rende le successive unioni più semplici e prive di errori.

Quindi CI è un processo automatizzato, in cui la build viene attivata ad ogni check-in del codice, viene compilata, crea build e gli unit test automatizzati vengono eseguiti sulla build.

Possiamo anche chiamare CI come COP o processo di controllo se il codice di tutti nel team è un codice buono o valido o meno, perché il processo CI, compila e costruisce immediatamente con ogni check-in e genera errori se si tratta di un codice non valido, oppure non può essere compilato o non può superare i casi di unit test automatizzati.

Quali sono i vantaggi di CI?

Prima di tutto, l'intero processo CI è un processo automatizzato e quindi riduce al minimo l'errore umano riducendo le lunghe fusioni manuali che causano errori.

Un numero qualsiasi di persone può effettuare il check-in del proprio codice, qualsiasi numero di volte in un giorno, senza attendere che gli altri completino la codifica, attendere il completamento del check-in e il check-in successivo. Quindi, CI rimuove la dipendenza o rimuove il tempo di attesa degli altri check-in.

Pertanto, i membri del team non devono aspettare che gli altri membri del team finiscano il loro check-in e quindi consentono di lavorare in parallelo.

Ogni check-in non si ferma alla raccolta al controllo della versione, ma viene immediatamente qualificato attraverso la formazione della build e il test automatizzato. Quindi, ogni check-in viene convalidato nella radice stessa per ulteriori elaborazioni.

Non c'è alcuna possibilità di perdere il codice di nessuno perché il codice di tutti viene archiviato nella copia master con il timestamp e quindi registrato correttamente.

L'intero processo di compilazione, creazione e test viene eseguito in pochi secondi e quindi molto più veloce e più veloce e consente di risparmiare molto tempo e quindi aiuta a raggiungere l'obiettivo DevOps di fornire più velocemente per un periodo di poche ore.

Poiché l'intero processo di creazione e test dura da pochi secondi a pochi minuti, il feedback sul codice delle persone è molto veloce e non dobbiamo correre per scoprire quale codice ha rotto la build o indotto il difetto, come con ogni check-in fornisce l'output di successo o fallimento che indica l'area di errore se c'è un errore.

Quindi, questo consente allo sviluppatore di controllare la piccola quantità di codice in modo intermittente, forse anche una singola riga di codice, per assicurarsi che sia privo di errori e fa sì che lo sviluppatore abbia la certezza che il proprio codice sia buono e inoltre non rompa gli altri codice. Quindi, questo in totale aiuta a migliorare la qualità del codice.

Fermiamoci qui e riprendiamo la consegna continua e il test continuo nei prossimi tutorial video.

Tutorial PREV | PROSSIMO Tutorial

Lettura consigliata

^