Il primo principio della Continuous Software Delivery dice di tenere tutto nel controllo di codice sorgente. Perchè?

All in a word: Configuration Management.

Se abbiamo automatizzare e rendere operativi gli ambienti di test, di staging, di produzione, la configurazione di server ed applicativi, e tutto quello che concerne la produzione di software, è necessario avere un repository centralizzato.

Quindi abbattiamo il “dogma” che vede solo il codice sorgente all’interno del VCS. All’interno del VCS dobbiamo avere tutto il necessario. Soprattutto le dipendenze giocano un ruolo chiave, visto che devono essere risolte in modo automatico.

Complementare ed altrettanto importante è avere dei messaggi che abbiano senso come commento al commit (changeset comments in Team Foundation Server), onde evitare di non sapere cosa stiamo prendendo ed il perchè dell’inserimento nel controllo di codice sorgente.

Aggiungo anche, che con i Team Foundation Server Power Tools, possiamo impostare delle regole (come quella che impone la scrittura di  changeset comments) che facilitano l’aderenza alle guidelines di team.

I check-in devono essere frequenti, e soprattutto eseguiti regolarmente nella trunk. Va prestata molta attenzione con le branch, visto che eseguire branch e poi scoprire problemi di integrazione al momento della merge è assolutamente antitetico alla Continuous Integration, che è fondamentale nel processo che stiamo analizzando. Strumenti di merge automatizzato non sono contemplati: le modifiche vanno unite a mano. Ci torneremo comunque su a tempo debito, se necessario

Tornando all’argomento chiave del post, la configurazione, la possiamo dividere in sottocategorie in base al momento in cui viene modificata:

• Build Time Configuration, ossia l’inserimento della configurazione al momento della creazione dei file binari
• Packaging Time Configuration, qui la configurazione viene iniettata durante la creazione di un pacchetto distribuibile, ad esempio un .msi
• Deployment Time Configuration, la configurazione viene solitamente catturata o inserita al momento dell’installazione
• Startup Configuration, che è quella che esegue una applicazione in modo automatico all’avvio

Solitamente vengono utilizzate le ultime due. Ed ovviamente si deve aveere un repository centrale anche della configurazione, da trattare con gli stessi criteri del codice sorgente.

Bisogna tener conto anche che versioni di sviluppo, UAT, performance testing, staging e produzione possono avere diverse configurazioni. Il consiglio è di trattarla come codice sorgente, e di creare un sistema strutturato (XML, per dirne uno) di storage.

Le configurazioni vanno testate (si, si possono scrivere unit test anche per questo), e devono inesorabilmente fallire se qualche prerequisito o dipendenza non è installato/funzionante correttamente. il Visual Studio Lab Management in questo è assolutamente essenziale

Il sistema di configurazione deve essere automatico e flessibile, e soprattutto seguire il principio DRY (don’t repeat yourself). Ripetere gli elementi di configurazione significherebbe ridondanza non necessaria e l’inserimento di ulteriori points of failure.

Questo è solo un piccolo tassello nella Continuous Delivery, nel prossimo…chissà