Semplice spiegazione dell'integrazione continua


32

Come definirebbe l'integrazione continua e quali componenti specifici contiene un server CI?

Voglio spiegare a qualcuno nel reparto marketing cos'è l'integrazione continua. Comprendono il controllo del codice sorgente, ovvero usano Subversion. Ma vorrei spiegare loro in modo corretto cos'è la CI. L' articolo di Wikipedia non lo definisce mai correttamente, l' articolo di Martin Fowler fornisce solo quanto segue, che è fondamentalmente una tautologia seguita da una vaga spiegazione di "integrazione":

L'integrazione continua è una pratica di sviluppo software in cui i membri di un team integrano il proprio lavoro frequentemente, di solito ogni persona si integra almeno quotidianamente, portando a più integrazioni al giorno. Ogni integrazione è verificata da una build automatizzata (incluso il test) per rilevare gli errori di integrazione il più rapidamente possibile.

Aggiornamento : ho inviato loro questa immagine, non riuscivo a trovarne una più semplice.

inserisci qui la descrizione dell'immagine

Aggiornamento 2 : feedback dal cap marketing (per il momento in cui c'erano 3 domande):

In realtà mi piacciono tutte e 3 le risposte, per diversi motivi. Ho voglia di accedere solo per ringraziarli tutti!

Ovviamente non può - quindi grazie per il suo nome :)

Aggiornamento 3 : Mi sono reso conto, guardando l'articolo di Wikipedia, che contiene i principi che, quando prendi solo le intestazioni, è una buona lista:

  1. Mantenere un repository di codice
  2. Automatizza la build
  3. Fai l'autotest della build
  4. Tutti si impegnano alla base ogni giorno
  5. Ogni commit (al basale) dovrebbe essere creato
  6. Mantieni la build veloce
  7. Test in un clone dell'ambiente di produzione
  8. Rendi facile ottenere gli ultimi risultati finali
  9. Tutti possono vedere i risultati dell'ultima build
  10. Automatizza la distribuzione

3
oO Il tuo dipartimento marketing utilizza Subversion? Tentato di votare per chiudere "Troppo localizzato" ... ;-)
Jeroen,

@Jeroen Sì, davvero, per i file sul sito web. Li ho trasformati in un bel grande pulsante rosso su una pagina Web che dice "Fallo" per aggiornare la sovversione sul server. :)
icc97,

Risposte:


27

Quando qualcuno modifica i file che compongono il prodotto software e quindi tenta di archiviarli (in altre parole, tenta di integrare le modifiche nel codice del prodotto principale), si desidera assicurarsi che il prodotto software possa ancora essere creato correttamente.

Di solito esiste un sistema esterno, chiamato server CI , che periodicamente o ad ogni modifica prenderà i file sorgente dal controllo versione e tenterà di costruire il prodotto (compilazione / test / pacchetto). Se il server CI può eseguire correttamente una build, le modifiche sono state integrate correttamente.

Il server CI deve anche essere in grado di trasmettere se la compilazione non è riuscita o è riuscita, quindi sistemi come Jenkins (uno dei server CI più utilizzati oggi) avranno modi di inviare e-mail / testi e un'interfaccia web simile a un dashboard con un mucchio di informazioni su build attuali e passate, chi ha fatto il check-in code, quando le cose si sono rotte, ecc. (Nella tua immagine sopra, questo sarebbe il meccanismo di feedback .)

L'IC è importante, perché garantisce che su base continua, si abbia un prodotto funzionante. Ciò è importante per tutti gli sviluppatori che stanno lavorando al prodotto software, nonché per tutte le persone che desiderano avere accesso alle versioni giornaliere del prodotto software, come il QA.


1
L'integrazione continua ha a cuore lo stato di compilazione, ma anche i test.
Quentin Pradet,

1
e la distribuzione, non è sufficiente per la compilazione e l'esecuzione dei test, ma è inoltre necessario inviare i file binari in un ambiente in modo che possano essere testati anche da persone (o strumenti automatizzati).
gbjbaanb,

1
Dato che la domanda richiedeva una semplice spiegazione, ho tralasciato molti dettagli (il più delle volte specifici per progetto / team) che potevano essere inseriti in un sistema CI.
c_maker,

Dipende dallo sviluppo guidato dai test? Il codice che compila non è sempre il codice che funziona bene? Senza i test che falliscono quando il codice non è pronto, come farebbe il sistema CI a sapere se il codice è stato effettivamente integrato con successo?
mowwwalker,

1
@ user828584: Nella mia risposta, sottintendo che "test" fa parte di una build. E come nota a margine, TDD è diverso dall'avere test per verificare la qualità. Come effetto collaterale del TDD, avrai dei test ben scritti, ma puoi fare dei test senza fare alcun TDD.
c_maker,

33

Immagino che per il tuo dipartimento marketing non sia importante il modo in cui CI funziona , ma cosa significa CI per le nuove versioni del tuo software .

Idealmente, CI intende produrre ogni giorno una nuova versione potenzialmente rilasciabile del software, pronta per essere presentata o venduta al cliente, con l'aggiunta di alcune nuove funzionalità, funzionalità o correzioni di errori. Ciò non significa che devi consegnare la nuova versione ogni giorno, ma puoi farlo se lo desideri.

Ad esempio, se hai pianificato di rilasciare ufficialmente un nuovo set di funzionalità per la versione "2015" del tuo software e hai parti di quel set di funzionalità già codificate e integrate oggi, i professionisti del marketing possono prendere la versione corrente del tuo software e mostrarlo - più o meno in modo sicuro - alla prossima conferenza ora nel 2013. Senza CI, dovevano chiedere al tuo team un blocco del codice non pianificato, ogni membro del team doveva integrare la funzionalità di mezzo su cui sta lavorando nel prodotto, potrebbero non avere abbastanza test automatici pronti e indovinare cosa accadrà alla conferenza - la "versione alfa" della tua versione 2015er avrà un rischio molto più elevato di crash, specialmente quando vengono dimostrate le nuove funzionalità.


4
+1 per l'approccio dal punto di vista del beneficio che offre.
colpì

17

Non puoi sapere cos'è la CI se non sai cosa facevamo. Immagina un sistema con 3 parti. C'è un'interfaccia utente che raccoglie i dati e li inserisce nel database. Esiste un sistema di reporting che crea report dal database. E c'è una sorta di server che monitora il database e invia avvisi e-mail se vengono soddisfatti determinati criteri.

Molto tempo fa questo sarebbe stato scritto come segue:

  1. Concordare lo schema per il database e i requisiti: ciò richiederebbe settimane perché doveva essere perfetto poiché vedrai presto perché
  2. Assegna 3 sviluppatori o 3 team indipendenti di sviluppatori ai 3 pezzi
  3. Ogni sviluppatore avrebbe lavorato sul proprio pezzo e testato il proprio pezzo usando la propria copia del database, per settimane o mesi.

Durante questo periodo gli sviluppatori non eseguivano il codice a vicenda, né cercavano di utilizzare una versione del database che era stata creata dal codice di qualcun altro. Lo scrittore di report aggiungerebbe semplicemente un mucchio di dati di esempio. Il writer degli avvisi aggiungeva manualmente record che simulavano eventi di report. E il writer della GUI avrebbe esaminato il database per vedere cosa aveva aggiunto la GUI. Nel tempo, gli sviluppatori si sarebbero resi conto che la specifica era in qualche modo sbagliata, come non specificare un indice o avere una lunghezza del campo troppo breve, e "risolverlo" nella loro versione. Potrebbero dire agli altri, che potrebbero agire su di esso, ma di solito queste cose andrebbero in un elenco per dopo.

Quando tutte e tre le parti fossero completamente codificate, testate dai loro sviluppatori e talvolta anche testate dagli utenti (mostrando loro un rapporto, una schermata o un avviso via e-mail), sarebbe arrivata la fase di "integrazione". Questo è stato spesso iscritto in bilancio per diversi mesi, ma sarebbe comunque andato oltre. Quella modifica della lunghezza del campo da parte di dev 1 sarebbe scoperta qui e richiederebbe agli sviluppatori 2 e 3 di apportare enormi modifiche al codice e, eventualmente, anche modifiche all'interfaccia utente. Quell'indice in più causerebbe il suo stesso caos. E così via. Se a uno degli sviluppatori fosse stato detto da un utente di aggiungere un campo, e ora sarebbe arrivato il momento in cui anche gli altri due dovevano aggiungerlo.

Questa fase è stata brutalmente dolorosa e praticamente impossibile da prevedere. Quindi la gente ha iniziato a dire "dobbiamo integrarci più spesso". "Dobbiamo lavorare insieme dall'inizio." "Quando uno di noi solleva una richiesta di modifica [è così che abbiamo parlato allora] gli altri devono saperlo." Alcuni team hanno iniziato a fare test di integrazione in precedenza continuando a lavorare separatamente. E alcuni team hanno iniziato a utilizzare il codice reciproco e l'output tutto il tempo, fin dall'inizio. E quello è diventato l'integrazione continua.

Potresti pensare che sto esagerando quella prima storia. Ho lavorato un po 'per un'azienda una volta in cui il mio contatto mi ha tirato fuori per aver controllato un codice che soffriva dei seguenti difetti:

  • uno schermo su cui non stava lavorando aveva un pulsante che non faceva ancora nulla
  • nessun utente aveva firmato il progetto dello schermo (colori e caratteri precisi; l'esistenza dello schermo, le sue capacità e quali pulsanti aveva nelle specifiche di 300 pagine)

Era sua opinione che non si mettesse roba nel controllo del codice sorgente finché non è FATTA. In genere faceva uno o due check-in un ANNO. Abbiamo avuto un po 'di differenza filosofica :-)

Inoltre, se trovi difficile credere che i team sarebbero disconnessi attorno a una risorsa condivisa come un database, non crederai davvero (ma è vero) che lo stesso approccio è stato adottato per il codice. Hai intenzione di scrivere una funzione che posso chiamare? È fantastico, vai avanti e fallo, nel frattempo deciderò semplicemente ciò di cui ho bisogno. Mesi dopo "integrerò" il mio codice in modo che chiami la tua API e scopriremo che esplode se passo null, esplode se restituisce null (e lo fa molto) restituisce cose troppo grandi per me, non può sopportare anni bisestili e mille altre cose. Lavorare in modo indipendente e quindi avere una fase di integrazione era normale. Ora sembra follia.


2
Abbiamo avuto una storia simile in cui abbiamo aggiornato un'applicazione personalizzata costruita da SP 2003 a SP 2007. Usando VSS (sì, VSS :), ogni sviluppatore ha verificato una parte del loro file, codificato per una settimana e due, quindi quando ci siamo integrati il nostro codice, boom, che quando il problema è iniziato da quando il nostro codice si è discostato in modo significativo. Abbiamo risolto il problema dell'integrazione per un mese e il progetto ha affittato un hotel per ospitare coloro che vivono molto lontano nei giorni feriali. In quel giorno, ho imparato a integrare il codice su base giornaliera :-)
Onesimus Nessun impegno,

@OnesimusUnbound Ricordo di essere stato urtato da VSS a Clearcase ... dalla padella al fuoco. Anni dopo, dopo essere tornato nella stessa azienda per un drink, ricordo che qualcuno rideva di un collega sviluppatore per aver menzionato questo nuovo controllo del codice sorgente chiamato "Git", "A cosa serve un altro sistema di controllo del codice sorgente ??".
icc97,

1
Grazie - ho faticato a capire la CI prima semplicemente perché non sapevo quale fosse l'alternativa
Rhys

Interessante. Per me, sembra più un paragone tra CI e cascata. Ma puoi usare una metodologia non a cascata che evita questi problemi (come lo sviluppo iterativo) e non usare CI.
Dan Molding,

@DanMoulding se sono agile e iterativo e quant'altro da parte mia di una cosa più grande che non è integrata con ciò che qualcun altro sta facendo, non sto facendo CI. Diamine, puoi cascata e CI. Progetta tutto, codifica tutto, prova tutto se vuoi - se tutti usano sempre il layout di codice / schema / file di tutti gli altri, questo è CI anche se stai usando la cascata. La connessione è che senza CI vivi e muori da BDUF perché questa è la tua unica speranza (e si rivela essere una debole speranza) di avere una fase di integrazione di una lunghezza ragionevole. L'adozione dell'IC ci ha permesso di lasciare andare BDUF.
Kate Gregory,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.