In questo post affronteremo i principi essenziali della Continuous Delivery.

Il prerequisito essenziale è l’automazione: in questo Powershell ci viene in soccorso.

A seguito il primo principio: tenere tutto nel controllo di codice sorgente. Niente roba da risolvere a runtime contattando file server, niente di simile. Tutto deve essere presente nel Source Control, in modo da rendere qualunque passaggio e modifica tracciata. Team Foundation Server gestisce tutto questo molto bene, in quanto accetta di tutto .

Mantenere tutto all’interno del controllo di codice sorgente implica anche gestirlo, questo tutto. Ci aiuta il progetto guidato da Mike Fourie (Visual Studio ALM Ranger) e con una serie di contributors di altissimo livello (Ed Blankenship, Grant Holliday, Martin Woodward ed anche il nostro Gian Maria), Community TFS Build Extensions. Sono una serie di estensioni di Team Build che permettono di compiere azioni non presenti out of the box in Visual Studio ALM 2010 (come eseguire Test Case scritti con NUnit) e possono fungere come building blocks per l’automazione.

Il secondo principio si appoggia a tutto ciò che è stato illustrato sinora: creare un processo ripetibile ed affidabile per il rilascio.
Ciò comporta non solo la copia dei files necessari in fase di installazione, ma anche la configurazione.

Come conseguenza di questo, abbiamo il terzo: se fa male, fallo più frequentemente e vai oltre il problema. Primo passo per osservare questo principio? Deploy automatico in un ambiente di staging ogni qualvolta tutta la suite di test automatici passa e generazione automatica di tutta la documentazione (con Sandcastle in Team Build ad esempio, utilizzando la Build Definition per la release).

Quarto: tutti sono responsabili del processo di deploy. Tutti. Anche il team di Operations. Quindi la comunicazione e l’eliminazione delle barriere fra developers e ferristi rappresenta la pietra angolare di questo principio.

Al prossimo post!