Cos'è l'integrazione continua (CI) e come è utile? [chiuso]

Integrazione continua in poche parole significa che si salva il lavoro, lo si spinge al sistema di gestione dei documenti (SVN nel proprio caso), tutti i test vengono eseguiti automaticamente (test di unità, integrazione, funzionale, ecc.) e l'applicazione è compilato e preparato per la consegna (cioè viene creata l'immagine ISO). L'integrazione continua non è la stessa cosa con la consegna continua. La consegna è ancora fatta in diversi momenti. CI garantisce che il prodotto possa essere consegnato se necessario, niente di più.

Ogni volta che qualcosa va storto, il team riceve una notifica. Di solito a quel punto tutto il lavoro è interrotto e tutti gli sforzi si concentrano sull'assicurare che il prodotto sia stabile. Nessun push e commit si verificano sul repository mentre il sistema non è verde.

CI garantisce che il prodotto sia sempre in uno stato stabile e potenzialmente possa essere consegnato in qualsiasi momento. Si prega di notare che stabile non significa funzione completa. Potrebbero esserci anche funzionalità implementate per metà, ma il sistema può essere stabile.

L'IC è solitamente associato a metodologie Agile, tuttavia non conosco personalmente la cronologia esatta di CI.

Integrazione continua significa che l'integrazione del codice in un prodotto che viene effettivamente eseguito e verificato può accadere in qualsiasi momento , non (come in precedenza) come un'attività separata in ritardo nel ciclo di vita dello sviluppo.

Richiede che il processo di compilazione dell'applicazione sia completamente automatizzato, una suite di test automatizzata e un server che costruisca lo stato corrente del codice e che esegua la suite di test su di esso. Questo dovrebbe accadere ogni giorno, o anche dopo ogni controllo del codice.

Il vantaggio è che esiste un feedback immediato sulle modifiche al codice che causano errori di compilazione (ad esempio perché lo sviluppatore non è riuscito a verificare tutte le modifiche o utilizza alcuni componenti non presenti nel sistema di generazione) o fallimenti del test case. Ciò rende questi errori molto più facili da risolvere, poiché sai quali cambiamenti li hanno causati e il responsabile ha ancora ricordi freschi di ciò che hanno fatto.

Senza CI, tutti questi errori emergono contemporaneamente durante la fase di integrazione, il che li rende estremamente difficili da risolvere.

Potresti avere uno stile certo in fase di sviluppo: checkout, codice, compilazione, controllo, imprecazione, modifica, compilazione, allegria, commit. Impegni solo il codice di lavoro, magari anche in un modo meno dettagliato come alla fine del tuo giorno lavorativo o quando una funzionalità è completa. Verifica le tue dipendenze ogni volta che importi le librerie API.

Quando inizi a programmare insieme agli altri e quando ci sono dipendenze reciproche, ha senso adottare un'integrazione continua. Semplicemente perché non puoi conoscere l'impatto delle modifiche sulle persone che dipendono dal tuo codice e non ricevi alcun segnale ogni volta che devi aggiornare le tue importazioni.

Quindi, quando ognuno di voi apporta una modifica, entrambi i progetti dovrebbero essere costruiti e testati insieme, cioè eseguiti l'uno contro l'altro, costruiti e testati con la nuova libreria, ecc. Tali test, il vostro codice e quelli di qualcun altro, sono chiamati integrazione test.

Perché continuo? Perché è più facile delegare il coordinamento dell'integrazione a un sistema che verifica una build pulita ogni volta che c'è un cambiamento in entrambi i code base piuttosto che organizzare tutto questo per un umano. Il sistema è in grado di ridimensionare.

Ci sono due aspetti dell'integrazione continua.

1. La strategia di controllo dei sorgenti di sviluppo garantisce che gli sviluppatori siano in grado di integrare continuamente il loro lavoro in corso con altri sviluppatori del codice stabile.
2. La costruzione e il test automatici del codice sorgente attivati da a commit al controllo del codice sorgente

Il punto 1 è fondamentale. È la mossa per rendere le fusioni che gli sviluppatori eseguono in realtà per essere frequenti e di natura ridotta che rende le fusioni molto più probabili per avere successo.

Il punto 2 sono gli strumenti e il framework necessari per consentire al punto 1 di verificarsi in modo sicuro, identificando rapidamente le unioni che hanno fallito interrompendo il codice esistente.

Quanto è utile?

Incredibilmente. Come sviluppatore che lavora su un progetto, consente di dedicare la maggior parte del tempo a concentrarsi su ciò che si sta facendo, senza preoccuparsi del lavoro concorrente del resto del team. Al termine del tuo lavoro corrente, pubblichi le modifiche al resto del team e nelle prossime ore tutte uniscono le modifiche nel loro lavoro corrente.

Senza di esso, gli sviluppatori stanno facendo il big bang. Di solito impiegano diversi giorni del loro lavoro e devono unirlo a tutte le modifiche apportate dal resto della squadra in una volta sola. Quando un'unione diventa notevolmente negativa, l'altro sviluppatore probabilmente si è spostato su un altro lavoro e sta iniziando a dimenticare i dettagli precisi per aiutare a disfare il pasticcio di fusione. Ancora peggio, senza il continuo sviluppo e test, finché il codice viene compilato, i bug possono essere visualizzati nel codice e non verranno raccolti finché i test (oi clienti) non li troveranno.

CI è utile quando hai:

• Compilazione del codice
• Serie di test effettiva
• Rapporti, basati sul codice sorgente dell'utente (copertura del codice, violenza degli standard del codice, ecc.)
• Routine che fai periodicamente, dopo che il codice è stato compilato con successo

L'elenco può essere continuato ..