Con l’ultima release dei Team Foundation Server 2010 Power Tools è stata integrata la ricerca già esistente in Team Explorer Everywhere e Team System Web Access.

Che ovviamente aprirà i risultati nel box sottostante:

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!

Se stai deployando il tuo software manualmente, lo stai facendo nel modo più sbagliato possibile.

Il concetto della Continuous Delivery è questo: unire team di sviluppo e team di sistemi di produzione per creare qualcosa di automatizzato e ripetibile, che abbatta costi e tempi di deploy e permetta di avere una gestione più flessibile di ciò che creiamo.

Ok, non è facile: bisogna essere continuamente production ready ed essere pronti a rilasciare in qualunque momento. Ci sono metodologie di sviluppo che aiutano questo ragionamento (Scrum), ma come sempre la metodologia o il tool vanno adattati nella realtà in cui ci si muove continuamente, non sono la semplice panacea di tutti i mali.

Prima di cominciare a parlare di Continuous Delivery, scopriamo quali sono i più classici antipattern che spesso si incontrano in fase di deploy.

Il primo è sicuramente quello del rilascio manuale. A seguire, il rilascio in un ambiente simile alla produzione (staging) solamente a sviluppo completato. Infine, la configurazione manuale degli ambenti di produzione.

Possiamo evitare tutto ciò? Decisamente si.

Partiamo da un primo aspetto comune a questi antipattern: la mancanza di feedback utile.

Rilasciamo manualmente? Un feedback è inutile, tardivo.
Rilasciamo in staging solo a sviluppo completato? Una segnalazione di bug è potenzialmente disastrosa.
Configuriamo manualmente gli ambienti di produzione? Un feedback significa che molto probabilmente è andato tutto storto.

Quindi la prima cosa fondamentale è integrare il feedback all’interno del processo di sviluppo. In Dev11 sarà uno dei pilastri (Actionable Feedback). E se io volessi già incorporarlo oggi, con l’attuale versione di Visual Studio ALM?

Posso farlo utilizzando Expression SketchFlow, innanzitutto. Ma posso farlo in modo ancora più esposto allo stakeholder, con delle release continue del mio prodotto, ad esempio. E soprattutto portando nell’ambiente di test (identico o in scala a quello di produzione) il codice in modo assolutamente incrementale e continuativo. Strumenti? Team Foundation Build e Visual Studio Team Lab Management.

Alla base di tutto ciò, ovviamente, deve esserci una quasi completa automazione dei processi di rilascio, di cui ci occuperemo in seguito.

I vantaggi sono evidentissimi: aumento esponenziale della flessibilità del team di sviluppo, riduzione degli errori e soprattutto immediate accomplishment dei desideri del cliente, senza uno spreco di risorse inevitabile.

Nel prossimo post ci occuperemo dei principi del Software Delivery.