Il ruolo della Continuous Integration all’interno della Continuous Software Delivery è essenziale, strutturale.

Partiamo dall’idea che la CI è un cambio totale di paradigma: se prima il software non funzionava quando qualcuno provava la configurazione, ora invece è sempre automaticamente verificato (considerando anche l’esecuzione di test automatizzati) ogni volta che viene inserito nel Source Control un qualche tipo di cambiamento.

Implementarla con Team Foundation Server è facilissimo: basta indicare nella Build Definition che si tratta di una build eseguita in CI:

ed ovviamente deve esistere almeno un Build Controller con un Build Agent, altrimenti Visual Studio restituirà un errore.

Per utilizzarla con profitto è necessario che i check in siano eseguiti con regolarità e con una granularità accettabile, e che ci sia una suite di test automatizzati completa. Questa suite deve essere eseguibile sia sulla macchina di sviluppo che su quella di build in modo indifferente.

L’uso di uno strumento di segnalazione per lo stato della build è caldamente consigliato. Si può utilizzare di tutto: c’è stato un periodo in cui era esplosa la moda dei Nabatztag, dei conigli elettronici, e c’era chi lo aveva collegato alla build come strumento di segnalazione, per quanto si possono utilizzare anche strumenti più convenzionali come schermi che riportano lo status

Nella Continuous Software Delivery è importante anche tenere in considerazione strumenti come Code Metrics, Code Coverage e Code Analysis: ci danno una panoramica di alto livello su alcuni specifici scenari (copertura da parte dei test per la Code Coverage, stile di scrittura del codice da parte della Code Analysis, metriche ingegneristiche per la Code Metrics) che spesso semplificano la fase analitica della risoluzione di un problema e portano ad un buon refactoring.