Costruisci automazione vs distribuisci automazione vs integrazione continua

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

• Costruire l'automazione sta automatizzando il modo in cui il software viene creato invece di richiamare manualmente il compilatore. Ciò avverrebbe tramite strumenti come ad es. Crea o Ant .

• L'automazione della distribuzione sta prendendo il tuo software e implementandolo o installandolo su un sistema di test o di produzione.

• Integrazione continua significa che un processo automatizzato crea il tuo software continuamente come sviluppatori controlla il codice ed esegui i test unitari per verificare che il codice funzioni ancora. Ad esempio, ogni 15 o 30 minuti che un server potrebbe riattivare, esegue la scansione di VCS per i nuovi check-in, quindi aggiorna e crea il progetto se sono state apportate modifiche. Oltre a eseguire passaggi di compilazione, questa è anche una grande opportunità per eseguire test unitari automatizzati e controlli di qualità del codice .

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

Per lo meno, hai bisogno di avere automazione di compilazione, ovvero uno script di compilazione di qualche tipo. Ciò consente di fare clic su un pulsante o emettere un comando per creare il tuo progetto. Il vantaggio di ciò è la riduzione degli errori durante l'esecuzione manuale dei passaggi. Gli ambienti di compilazione complessi potrebbero comportare la generazione di codice (si pensi DAO da configurazioni, codice di interfaccia come JAXB ), compilando il codice, impacchettandolo, personalizzando i metadati, ecc. Con un sacco di cose da fare hai bisogno di una lista di controllo: perché non fare in modo che la checklist sia la tua build script e utilizzare uno strumento per eseguirlo? Riduce gli errori e fornisce coerenza.

Il prossimo è CI: questo è veramente buono da avere ma non strettamente richiesto. Aiuta a identificare i problemi di costruzione in anticipo. Se ci sono più sviluppatori che controllano il codice durante il giorno e forse non sincronizzano costantemente i propri spazi di lavoro, c'è il rischio che i loro cambiamenti interferiscano l'uno con l'altro. 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 le fasi di implementazione. L'idea qui è di risparmiare tempo e ridurre l'errore derivante dall'implementazione manuale del software. Proprio come l'automazione delle build, ci sono cento modi per rovinare una distribuzione del software. Sono rimasto in ritardo in ufficio per risolvere i problemi di distribuzione manuale in molte occasioni in cui abbiamo bisogno di un sistema funzionante per i clienti che verranno domani sul posto. L'automazione di più sistemi introduce più rischi: invece di un sistema che si blocca o presenta errori strani, ora abbiamo più sistemi che possono andare storto. Tuttavia, tale rischio è di gran lunga inferiore rispetto a qualcuno che manca un passo su una lista di controllo o che emette il comando sbagliato e incasina una distribuzione. Se sei fortunato puoi semplicemente ripristinare un backup del DB e ricominciare da capo, se sei sfortunato un errore potrebbe causare un 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 unire 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 i team tradizionali 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 automatizzati della mainline condivisa per trovare i probalemi in anticipo, ma è più incentrata sui commit frequenti e sul flusso di lavoro degli sviluppatori che su devops.

• Le build automatiche sono preziose per raccogliere i problemi che potrebbero causare il passaggio della build localmente, ma falliscono sul server di build (ad es. hai dimenticato di archiviare un file, le dipendenze sul server di build non corrispondono) . Avere il build server in grado di rilevare questi problemi significa che puoi correggerli prima dei tuoi compagni di squadra.

• La consegna continua comporta la distribuzione, l'esecuzione e il collaudo continui del software. Mentre le build automatizzate assicurano che il software sia effettivamente costruito (e che i test delle unità passino), ciò non significa che gli script di distribuzione funzionino ancora o che il software sia effettivamente eseguito end-to-end. L'obiettivo di Continuous Delivery consiste in una serie di controlli che assicurano che la linea principale rimanga in uno stato adatto per l'implementazione alla produzione.

• La Distribuzione continua è il prossimo passo logico: distribuire automaticamente ogni commit che passa con successo attraverso la pipeline di consegna continua. Ci sono molti vantaggi in questa pratica, ma per me l'idea principale qui è che i piccoli commit frequenti sono meno rischiosi.

Raccomando di leggere questo libro per ulteriori informazioni:

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

Teamcity come molti degli strumenti di creazione è solo un'app centrale che ti consente di eseguire molte attività diverse. Ciò include l'esecuzione di build come build CI, versioni complete e consente di eseguire distribuzioni. Se stai usando teamcity per chiamare ant o nant per eseguire msbuild su un file di soluzione, puoi anche chiamare gli script nant che eseguiranno i deploys. Potrebbe richiedere un po 'di scripting, ma non è difficile.

Utilizziamo teamcity e bamboo per gli elementi della configurazione, gli elementi della configurazione del database e i deployment nell'ambiente INTegration. Quindi usiamo teamcity per creare build completi e creare script di migrazione db automaticamente. Questi vengono controllati in SVN tramite i lavori di teamcity che chiamano script nant. Per i deploys, avete indovinato, usiamo teamcity per chiamare su 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 .