Oggi ci occuperemo della storia del termine, discuteremo le complessità dell'implementazione del CI e presenteremo alcuni strumenti popolari che possono aiutare a lavorarci.
/ Flickr / / / Фото изменено
Termine
Continuous Integration (integrazione continua) è un approccio allo sviluppo di applicazioni che prevede frequenti build del progetto e test del codice.
L'obiettivo è rendere il processo di integrazione prevedibile e scoprire potenziali bug e errori in una fase precoce, in modo da avere più tempo per correggerli.
Il termine Continuous Integration è apparso per la prima volta nel 1991. Fu coniato dal creatore del linguaggio UML (Grady Booch). L'ingegnere presentò il concetto di CI come parte della propria pratica di sviluppo — . Egli intendeva l'affinamento incrementale dell'architettura nella progettazione di sistemi orientati agli oggetti. Grady non specificò requisiti per l'integrazione continua. Ma successivamente, nel suo libro «», affermò che l'obiettivo della metodologia era accelerare il rilascio di «rilasci interni».
Storia
Nel 1996, CI fu adottato dai creatori della metodologia (XP) — (Kent Beck) e (Ron Jeffries). L'integrazione continua divenne uno dei dodici principi fondamentali del loro approccio. I fondatori dell'XP specificarono i requisiti per la metodologia CI e sottolinearono l'importanza di effettuare build del progetto più volte al giorno.
All'inizio degli anni 2000, la metodologia di integrazione continua fu promossa da uno dei fondatori di Agile Alliance, (Martin Fowler). I suoi esperimenti con il CI portarono alla creazione del primo strumento software in questo campo — CruiseControl. L'utilità fu creata dal collega di Martin, Matthew Foemmel.
Il ciclo di build nello strumento è implementato come un demone che controlla periodicamente il sistema di controllo versioni per cambiamenti nella base di codice. La soluzione è ancora disponibile per il download oggi — è sotto licenza simile a BSD.
Con l'arrivo del software per il CI, sempre più aziende iniziarono ad adottare la pratica. Secondo uno studio di Forrester [pagina 5 ], nel 2009 l'86% delle cinquanta aziende tecnologiche intervistate utilizzava o stava implementando metodi CI.
Oggi la pratica di Continuous Integration è adottata da organizzazioni di diversi settori. Nel 2018, un importante provider cloud ha condotto un sondaggio tra professionisti IT di aziende attive nei servizi, nell'istruzione e nella finanza. Di tremila rispondenti, il 58% ha dichiarato di utilizzare strumenti e principi di CI nel proprio lavoro.
Come funziona
La base della Continuous Integration è costituita da due strumenti: il sistema di controllo versione e il server CI. Quest'ultimo può essere sia un dispositivo fisico che una macchina virtuale in un ambiente cloud. Gli sviluppatori caricano nuovo codice uno o più volte al giorno. Il server CI copia automaticamente il codice con tutte le dipendenze e compie il build. Successivamente, esegue i test di integrazione e unità. Se i test hanno esito positivo, il sistema CI distribuisce il codice.
Lo schema generale del processo può essere rappresentato come segue:

La metodologia CI presenta una serie di requisiti per gli sviluppatori:
- Correggere i problemi immediatamente. Questo principio è derivato dallo sviluppo agile. Correggere i bug è la priorità principale degli sviluppatori.
- Automatizzare i processi. Gli sviluppatori e i manager devono costantemente cercare i "colli di bottiglia" nel processo di integrazione e eliminarli. Ad esempio, spesso il "collo di bottiglia" dell'integrazione il testing.
- Eseguire build il più frequentemente possibile. Almeno una volta al giorno, per sincronizzare il lavoro del team.
Difficoltà nella loro implementazione
Il primo problema sono i costi operativi elevati. Anche se l'azienda utilizza strumenti CI open source (di cui parleremo più avanti), dovrà comunque spendere soldi per mantenere l'infrastruttura. Tuttavia, le tecnologie cloud possono essere una soluzione.
Esse semplificano il build di configurazioni informatiche di diverse dimensioni. Inoltre, le aziende pagano solo per le risorse utilizzate, il che aiuta a risparmiare sull'infrastruttura.
Secondo i sondaggi [стр.14 ], la Continuous Integration aumenta il carico di lavoro dei dipendenti dell'azienda (almeno nel primo periodo). Devono familiarizzare con nuovi strumenti, e i colleghi non sempre aiutano nell'apprendimento. Pertanto, si è costretti a districarsi con i nuovi framework e servizi "al volo".
La terza difficoltà sono i problemi di automazione. Le organizzazioni con un grande volume di codice legacy, che non è coperto da test automatizzati, si trovano ad affrontarli. Questo porta a riscrivere il codice prima di un'implementazione completa del CI.

/ Flickr / /
Chi lo usa
Tra i primi a riconoscere i vantaggi della metodologia ci sono stati i giganti dell'IT. Google ha implementato l'integrazione continua a partire dalla metà degli anni 2000. Hanno introdotto il CI per risolvere il problema dei ritardi nel funzionamento del motore di ricerca. L'integrazione continua ha aiutato a rilevare e risolvere rapidamente i malfunzionamenti. Ora il CI è utilizzato da tutti i reparti del colosso IT.
L'integrazione continua aiuta anche le piccole aziende, e inoltre gli strumenti CI vengono utilizzati da organizzazioni finanziarie e sanitarie. Ad esempio, in Morningstar, i servizi di integrazione continua hanno aiutato a correggere le vulnerabilità il 70% più velocemente. E la piattaforma medica Philips Healthcare è riuscita a raddoppiare la velocità di test degli aggiornamenti.
Strumenti
Ecco alcuni strumenti popolari per il CI:
- — uno dei sistemi CI più popolari. Supporta oltre mille plugin per l'integrazione con diversi VCS, piattaforme cloud e altri servizi. Utilizziamo Jenkins anche noi in 1cloud: questo strumento . Controlla regolarmente il ramo Git destinato ai test.
- — un framework Python per la scrittura dei propri processi di integrazione continua. La configurazione iniziale dello strumento è piuttosto complessa, ma questo è compensato da ampie possibilità di personalizzazione. Tra i suoi punti di forza, gli utenti segnalano il basso consumo di risorse del framework.
- — un server di Pivotal che utilizza i container Docker. Concourse CI si integra con qualsiasi strumento e sistema di controllo delle versioni. Gli sviluppatori notano che il sistema è adatto per lavorare in aziende di qualsiasi dimensione.
- — uno strumento integrato nel sistema di controllo delle versioni GitLab. Il servizio opera nel cloud e utilizza file YAML per la configurazione. Come Concourse, Gitlab CI container Docker, che aiutano a isolare i vari processi l'uno dall'altro.
- — un server CI cloud che funziona con GitHub, GitLab e BitBucket. La piattaforma non richiede lunghe configurazioni iniziali: in Codeship sono disponibili processi CI preimpostati standard. Per progetti piccoli (fino a 100 build al mese) e open source, Codeship è disponibile gratuitamente.
Materiali dal nostro blog aziendale:
Fonte: habr.com
