Costruisci automazione vs distribuisci automazione vs integrazione continua

Voglio diventare più efficiente e voglio usare gli strumenti operativi in ​​modo efficiente.

Con questo in mente, volevo saperne di più sull'integrazione continua, ma sembra che ci siano molte cose diverse al riguardo.

In realtà sto lavorando con le tute Jetbrains nel mio lavoro (IntelliJ, WebStorm ...), quindi volevo continuare a usarle e volevo usare TeamCity che sembrava essere un ottimo strumento con molti plugin per una continua integrazione.

Il mio problema è che non so quali sono le differenze tra:

• building automation (TeamCity è questo tipo di software): so che possiamo costruire la nostra applicazione con un repository VCS remoto ed è grandioso, ma qual è l'obiettivo principale? Che tipo di informazioni è importante mentre lo fai? In effetti, so già se il mio software si sviluppa o meno localmente e anche i miei compagni di squadra. Quindi, qual è lo scopo di usarlo senza distribuire l'automazione?

• distribuzione dell'automazione (TeamCity non sembra farlo facilmente)

• integrazione continua (che sembra essere una congiunzione delle due sopra)
• consegna continua (che cos'è esattamente? perché è diverso dall'integrazione continua?)

Potete aiutarmi a capire un po 'di più questo?

Wikipedia fornisce riassunti abbastanza buoni della maggior parte di questi termini. Ecco la mia opinione su di loro:

• L'automazione della build sta automatizzando la modalità di creazione del software anziché richiamare manualmente il compilatore. Ciò sarebbe realizzato tramite strumenti come ad esempio Make o Ant .

• L'automazione della distribuzione sta prendendo il tuo software integrato e lo sta distribuendo o installando su un sistema di test o produzione.

• Integrazione continua significa avere un processo automatizzato che costruisce il software continuamente mentre gli sviluppatori effettuano il check-in del codice ed eseguono test unitari per assicurarsi che il codice funzioni ancora. Ad esempio, ogni 15-30 minuti un server potrebbe riattivarsi, scansionare VCS per nuovi check-in, quindi aggiornare e costruire il progetto se sono state apportate modifiche. Oltre a eseguire i passaggi di compilazione, questa è anche un'ottima opportunità per eseguire test di unità automatizzati e controlli di qualità del codice .

• La consegna continua è una combinazione di tutti i concetti precedenti in cui le build del software sono anche distribuite a un sistema di test, facoltativamente con test eseguiti e report generati.

Per lo meno, è necessario disporre dell'automazione della build, ovvero uno script di build di qualche tipo. Ciò ti consente di fare clic su un pulsante o emettere un comando per creare il tuo progetto. Il vantaggio di ciò è la riduzione degli errori dai passaggi eseguiti manualmente. Ambienti di compilazione complessi potrebbero comportare la generazione di codice (pensa a DAO da configurazioni, codice di interfaccia come JAXB ), compilazione di codice, impacchettamento, personalizzazione di metadati, ecc. Con un sacco di cose da fare hai bisogno di una lista di controllo: perché non fare in modo che la lista di controllo sia lo script di compilazione e utilizzare uno strumento per eseguirlo? Riduce gli errori e fornisce coerenza.

Il prossimo è CI: questo è davvero bello da avere ma non strettamente necessario. Aiuta a identificare precocemente i problemi di costruzione. Se hai più sviluppatori che effettuano il check-in del codice durante il giorno e forse non sincronizzi costantemente le proprie aree di lavoro, c'è il rischio che le loro modifiche interferiscano l'una con l'altra. Mi riferisco specificamente agli errori di codice statico, non ai conflitti di controllo della versione. Un server di build CI mitigherà questo rischio.

Finalmente abbiamo i passaggi di implementazione. L'idea qui è di risparmiare tempo e ridurre l'errore dalla distribuzione manuale del software. Proprio come l'automazione della compilazione, ci sono centinaia di modi per rovinare una distribuzione del software. Sono stato personalmente in ritardo in ufficio a risolvere i problemi di distribuzione manuale in molte occasioni in cui abbiamo bisogno di un sistema funzionante per i clienti che verranno sul posto domani. L'automazione di più sistemi comporta un rischio maggiore: invece di un sistema che potrebbe bloccarsi o avere strani errori, ora ne abbiamo piùsistemi che possono andare storti. Tuttavia, tale rischio è di gran lunga inferiore rispetto a quello in cui qualcuno manca un passaggio in una lista di controllo o emette un comando errato e incasina una distribuzione. Se sei fortunato puoi semplicemente ripristinare un backup del DB e ricominciare, se sei sfortunato un errore potrebbe causare il malfunzionamento del sistema. È un difetto del software? Il tecnico non ha impostato correttamente una configurazione? Questo richiede tempo per diagnosticare, tempo che potresti non avere e tempo che non è necessario spendere se automatizzi il processo.

• L'integrazione continua è la pratica di fondere tutte le modifiche degli sviluppatori in una linea principale condivisa più volte al giorno. Questa pratica è ora così onnipresente che potrebbe non sembrare così significativa, tuttavia tradizionalmente i team lavorerebbero su software per settimane o addirittura mesi in isolamento. Il risultato è stato "Integration Hell" quando flussi di lavoro separati sono stati uniti. L'integrazione continua viene normalmente utilizzata con build automatizzate della mainline condivisa per individuare tempestivamente i problemi, ma si tratta più di commit frequenti e flusso di lavoro degli sviluppatori che di DevOps.

• Le build automatizzate sono utili per rilevare problemi che potrebbero causare il passaggio locale della build, ma non riescono sul server di build (ad esempio, hai dimenticato di archiviare un file, le dipendenze sul server di build non corrispondono). Avere il server di build in grado di rilevare questi problemi significa che puoi risolverli prima dei tuoi compagni di squadra.

• La consegna continua implica l'implementazione, l'esecuzione e il collaudo continui del software. Mentre le build automatizzate assicurano che il tuo software sia effettivamente compilato (e i test unitari superano), ciò non significa che gli script di distribuzione funzionino ancora o che il tuo software sia effettivamente eseguito end-to-end. L'obiettivo della consegna continua è quello di disporre di una serie di controlli che garantiscano che la linea principale rimanga in uno stato adatto per la distribuzione alla produzione.

• La distribuzione continua è il passo logico successivo: la distribuzione automatica di ogni commit che passa correttamente attraverso la pipeline di distribuzione continua. Questa pratica offre numerosi vantaggi, ma per me l'idea principale qui è che piccoli e frequenti impegni sono meno rischiosi.

Consiglio di leggere questo libro per ulteriori informazioni:

• Consegna continua: rilasci di software affidabili tramite automazione di build, test e distribuzione

Teamcity come molti degli strumenti di compilazione è solo un'app centrale che ti consente di eseguire molte attività diverse. Ciò include l'esecuzione di build come build CI, build a rilascio completo e consente di eseguire distribuzioni. Se si utilizza teamcity per chiamare ant o nant per eseguire msbuild su un file di soluzione, è anche possibile chiamare script nant che eseguiranno le distribuzioni. Potrebbe richiedere un po 'di scripting ma non è difficile.

Usiamo teamcity e bamboo per CI completi, Database CI e si distribuisce nell'ambiente INTegration. Quindi utilizziamo teamcity per build a rilascio completo e creazione automatica di script di migrazione db. Questi vengono registrati in SVN tramite lavori di teamcity che invocano script nant. Per le distribuzioni, avete indovinato, usiamo teamcity per chiamare Nant per eseguire le attività di distribuzione. Funziona bene poiché l'agente di teamcity parla con il server di teamcity e l'agente può esistere su uno dei server in una posizione DMZ che aiuta a spostare il codice oltre i firewall, ecc. Quindi teamcity o bamboo è tutto ciò che serve per gestire l'intero scenario .