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.