Alle volte resto sconcertato: la maggior parte delle persone pensa che l’unica cosa importante per fornire il classico “programmino” ad un cliente sia scriverlo. Non mi stancherò mai di ripeterlo: il nostro obiettivo in qualità di sviluppatori è CONSEGNARE il software e non solamente scriverlo. Ecco perchè il processo di release/deploy di un software è di estrema importanza per la qualità e la gestione del ciclo di vita del software stesso.
Inoltre, non si deve mai dimenticare che il processo di rilascio di un software deve essere ripetibile, ovvero non devo ogni volta impazzire dietro a mille variabili per rilasciare la nuova versione del programma al mio cliente. Alcuni degli errori/cattive abitudini nel rilascio di un software possono essere annoverate tra:
- Cattiva gestione (o addirittura non gestione) del versioning: se non gestiamo il versioning, non sapremo mai che versione del software sta usando il nostro cliente, con il risultato che se ci riporta un baco, non sapremo mai se l’abbiamo già risolto
- Impiego di un controllo del codice sorgente “fatto in casa” (tipo zip dei file di progetto, per intenderci): questo è piuttosto grave, in quanto non riusciamo ad avere una traccia delle precedenti versioni del progetto, nè possiamo “ripristinare” una precedente versione per simulare un bug riscontrato in sede dal cliente
- Scarsa (o addirittura nulla, sigh!) documentazione dei prerequisiti per far funzionare il software: avete promesso un software fighissimo, lo sviluppate su XP, quando lo consegnate venite a sapere che il cliente impiega Vista e, per qualche “leggerezza” (leggi bad habit) di programmazione, su Vista il tutto non funziona.
- Assenza di un qualsivoglia file/documento/vademecum/aiuto per l’installazione e la configurazione: alle volte non saremo noi ad installare il software, ma qualcun altro. In questi casi, ma anche se saremo sempre noi a farlo, perchè fra tre mesi mi sarò dimenticato a cosa serve il campo XYZ nel file web.config che DOVEVA assumere il valore 345, è bene produrre e tenere aggiornato un documento che illustri con sufficiente dettaglio cosa si deve fare per installare correttamente il software
- Assenza di un ambiente di test per il deployment: questa “bad habit” è piuttosto comune ed è la causa del famoso “baco pigliatutto”: “ma da me funziona!” (macchina dello sviluppatore). I veri problemi di deployment emergono in fase di deployment. Punto. Quindi bisogna simularla, esattamente come si farebbe con un qualunque altro test.
- Gestione errata o assente dell’aggiornamento del database (se il software ne impiega uno, ovviamente). Questo è uno dei tasti più dolenti, in quanto è veramente un grosso lavoro mantenere aggiornati gli script di allineamento del database. Del resto ho visto troppe volte cose VERAMENTE brutte fatte per mantenere aggiornati database di produzione e database di sviluppo. La strada qui è una sola: bisogna gestire le versioni e gli aggiornamenti del database con gli script che devono poter essere lanciati in sequenza, a partire da una certa versione di partenza del database.
Gestire un buon processo di release e deployment non è una cosa da sottovalutare: è un’attività tanto importante quanto la scrittura di un buon codice. A mio parere, anche il prodotto più piccolo merita di avere una buona gestione del processo di release, in quanto il tempo speso si ripagherà con i grattacapi in meno che avremo in futuro, durante il ciclo di vita dei vari rilasci.