Il mio Makefile - I
Sviluppando in ambiente Linux, di solito per i miei progetti utilizzo dei Makefile che regolano una serie di processi automatici, come la compilazione, la messa in esercizio, il test, la generazione di file derivati etc.
Ad esempio, per un'applicazione web il comando make deploy scatena l'eventuale compilazione, la generazione di un pacchetto in formato deb o tgz, il trasferimento e l'installazione sul server, che di solito richiede un restart di Apache.
Di solito effettuo commit molto frequenti dei miei progetti, ma solo occasionalmente faccio un deploy. E a volte si pone il problema: quale versione è quella online? Avevo già effettuato la tal modifica? Avevo già integrato quella certa funzionalità?
Per tracciare i deploy e sapere qual'è la versione dell'applicazione in esercizio (o quale era in esercizio a un dato momento), è molto utile creare un tag nel sistema di controllo delle versioni. Un tag è un nome associato a una particolare versione dei file del progetto, una specie di istantanea della directory di lavoro a cui si può fare riferimento. Usando subversion, la sintassi all'interno del Makefile è la seguente:
tag: svn update svn commit svn cp . file:///path/to/svn/repo/tags/project_name-`date +"%Y.%m.%d.%H.%M"`
Con il comando make tag vengono lanciati in sequenza:
- Un update per aggiornare dal repository eventuali modifiche non integrate nella versione di lavoro. In questa fase possono essere rilevati dei conflitti, che è bene risolvere prima di fare un deploy.
- Un commit, per salvare nel repository le modifiche correnti.
- Un tag, che in subversion è semplicamente una copia della versione corrente della directory di lavoro. Il nuovo nome, tramite il comando date invocato tra
backtick , contiene la data corrente. Ad esempio, se il progetto si chiama nextgenweb, il nome del tag può essere nextgenweb-2008.12.01.20.15.
La data contiene nell'ordine le specifiche temporali in ordine big-endian (partendo dall'anno e proseguendo con mese, giorno etc.). Tutti i valori hanno larghezza fissa (4 cifre per l'anno, 2 per le altre unità). In questo modo, l'ordine temporale coincide con quello alfabetico ed è facile trovare all'interno di un listato l'ultima versione, la prima, la più recente dopo una certa data e così via.
Dopo una sessione estenuante di debugging o implementazione di nuove funzionalità, il pensiero è concentrato solo sul mettere online il nuovo prodotto (corretto o migliorato) il più velocemente possibile. È facile che altre pratiche importantissime, come il testing e il tagging della versione, siano messe momentaneamente da parte, con la sincera convinzione che ci si penserà in un secondo tempo. Convinzione che verrà sistematicamente disattesa. Per questo, è importante che l'operazione di deploy lanci in automatico testing e tagging. Nel Makefile, ci sarà qualcosa tipo:
tag: svn update svn commit svn cp . file:///path/to/svn/repo/tags/project_name-`date +"%Y.%m.%d.%H.%M"` test: comandi_di_test ... deploy: test tag upload && lancia ...Meglio ancora se al deploy segue un ulteriore test sulla versione in produzione dell'applicazione, che si assicuri ad esempio se il web server è ripartito correttamente (potrebbe essersi bloccato a causa di una configurazione errata), se l'applicazione contatta correttamente il DB etc. Per un sito web, una singola chiamata a una pagina con la verifica che questa contenga una certa stringa può già da sola metterci al riparo da molte tipologie di problemi.