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

Qualcuno può spiegarmi il concetto di integrazione continua, come funziona in modo facile da capire? E perché un'azienda dovrebbe adottare elementi della configurazione nel flusso di lavoro di consegna del codice? Sono uno sviluppatore e la mia azienda (principalmente il team di build) utilizza Team City. Come sviluppatore, eseguo sempre il checkout, l'aggiornamento e il commit del codice in SVN, ma non ho mai dovuto preoccuparmi di TeamCity o CI in generale. Quindi vorrei capire qual è l'utilità di CI? L'IC fa parte delle metodologie Agile?

La continua integrazione in breve significa che si salva il lavoro, lo si spinge nel sistema di gestione dei documenti (SVN nel proprio caso), tutti i test vengono eseguiti automaticamente (test di unità, integrazione, funzionamento, ecc.) E l'applicazione viene compilata e preparata per la consegna (es. immagine ISO creata). L'integrazione continua non è la stessa con la consegna continua. La consegna viene ancora effettuata 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 viene interrotto e tutti gli sforzi si concentrano per assicurarsi che il prodotto sia stabile. Nessuna spinta 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 noti che stabile non significa che la funzionalità è completa. Potrebbero esserci anche funzionalità implementate a metà, ma il sistema può essere stabile.

L'IC è solitamente associato alle metodologie Agile, tuttavia non conosco personalmente la storia esatta dell'IC.

Integrazione continua significa: l'integrazione del codice in un prodotto che viene effettivamente eseguito e può essere testato avviene sempre , non (come in precedenza) come attività separata nelle fasi avanzate del ciclo di 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 ed esegua la suite di test su di esso. Ciò dovrebbe avvenire quotidianamente o anche dopo ogni check-in del codice.

Il vantaggio è che ci sono feedback immediati sulle modifiche al codice che causano errori di compilazione (ad es. Perché lo sviluppatore non è riuscito a controllare tutte le modifiche o utilizza alcuni componenti non presenti nel sistema di compilazione) o errori del test case. Ciò rende tali errori molto più facili da correggere, poiché sai quale cambiamento li ha causati e la persona responsabile ha ancora nuovi ricordi di ciò che ha fatto.

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

Potresti avere un certo stile in fase di sviluppo: checkout, codice, compilazione, controllo, maledizione, modifica, compilazione, tifo, commit. Impegni solo il codice di lavoro, forse anche in modo meno granulare come alla fine della giornata di lavoro o quando una funzionalità è completa. Verifichi le tue dipendenze ogni volta che importi librerie API.

Quando inizi a programmare insieme ad 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.

Pertanto, quando uno di voi apporta una modifica, entrambi i progetti devono essere creati e testati insieme, ovvero eseguiti l'uno contro l'altro dell'API, creati e testati con la nuova libreria, ecc. Tali test, il codice e quelli di qualcun altro, sono chiamati test di integrazione.

Perché continuo? Perché è più semplice delegare il coordinamento dell'integrazione a un sistema che testa una build pulita ogni volta che c'è una modifica in una base di codice piuttosto che organizzare tutto ciò per un essere umano. Il sistema è in grado di ridimensionare.

Vi sono due aspetti per l'integrazione continua.

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

Il punto 1 è critico. È la mossa per rendere le fusioni che gli sviluppatori eseguono effettivamente per essere frequenti e di piccole dimensioni che rendono molto più probabile che le fusioni abbiano successo.

Il punto 2 è lo strumento e il framework necessari per consentire che il punto 1 si verifichi in modo sicuro, identificando rapidamente le fusioni non riuscite rompendo il codice esistente.

Quanto è utile?

Incredibilmente. Come sviluppatore che lavora a un progetto, ti consente di dedicare la maggior parte del tuo tempo a concentrarti su ciò che stai facendo e di non preoccuparti del lavoro concomitante del resto del team. Quando il tuo lavoro attuale è completo, pubblichi le modifiche nel resto del team e nelle prossime ore uniscono tutte le modifiche al loro lavoro attuale.

Senza di essa, gli sviluppatori stanno facendo delle fusioni di big bang. In genere richiede diversi giorni di lavoro e deve unirlo a tutte le modifiche apportate dal resto della squadra in una volta sola. Quando un'unione va notevolmente male, l'altro sviluppatore probabilmente si sarà spostato su altri lavori e inizierà a dimenticare i dettagli precisi per aiutare a deselezionare il pasticcio di unione. Ancor peggio, senza la continua costruzione e test, finché il codice viene compilato, unire i bug può apparire nel codice e non verrà raccolto fino a quando i test (o i clienti) non li troveranno.

CI è utile quando si dispone di:

• Compilazione del codice
• Set effettivo di test
• Rapporti, basati sul codice sorgente (copertura del codice, violenza sugli standard del codice, ecc.)
• Routine eseguita periodicamente, dopo aver compilato correttamente il codice

L'elenco può essere continuato ..