Versionamento di database
Uno dei riti di passaggio nella vita dello sviluppatore è l'adozione di un sistema di controllo delle versioni. Dopo aver appreso sulla propria pelle la necessità di una disciplina di backup, di solito a seguito di un evento traumatico quale la perdita di un mese di lavoro a causa di un delete un po' affrettato, il giovane sviluppatore comincia a disseminare i suoi dispositivi di supporto di file dai nomi poco edificanti quali torre-di-hanoi.zip, torre-di-hanoi-1.zip, torre-di-hanoi-138-bis.zip. Preso contatto con la nobile tradizione delll'ISO 8601, i file cominciano ad avere una forma un po' più coerente, quale torre-di-hanoi-2008-12-28.zip, il che gli evita di dover tenere conto dell'ultimo identificativo usato per un certo progetto e di cancellare i backup precedenti ad una certa data.
Il passaggio ad un sistema di controllo delle versioni quale subversion o uno dei suoi parenti più o meno stretti è un grande salto di qualità. I backup sono ben organizzati, è possibile navigare in maniera facile tra le varie versioni di un file e organizzare il lavoro con un team di sviluppo. Per salvaguardare il proprio lavoro da eventi catastrofici, basta fare il backup del repository.
Quando si sviluppa un progetto web, come questo sito, ci sono due componenti disomogenee da tutelare: la parte strutturale (codice sorgente, html, fogli di stile, immagini) e i contenuti che vengono man mano aggiunti e la cui perdita comporterebbe un grave danno, con conseguente depressione, perdita dell'appetito, comunicazione a mugugni e effetti annessi. Se i contenuti dinamici sono gestiti in un database, come è prassi normale, sarebbe utile avere anche questo sotto controllo di versione. Questo ci permetterebbe ad esempio di risalire a una versione precedente a un atto di vandalismo da parte di visitatori scontenti, di controllare la differenza con il testo di un post a un certo momento, di risalire, al decimo anniversario della prima messa on-line, alla situazione di origine per un momento nostalgico di amarcord.
Il problema nel versionamento di un DB è che il file (o insieme di file) in cui i dati vengono salvati su disco è visto come un unico blocco binario e questo rende difficile il salvataggio efficiente (che di solito prevede la sola memorizzazione delle differenze tra una versione e la successiva) nonché una navigazione sensata tra le varie versioni.
Un sistema che funziona molto bene nel caso di database di dimensioni ragionevoli (quali quelli che supportano un sito di media complessità) è quello di fare il versionamento di un dump testuale. Si usa uno degli strumenti che effettuano il backup del DB in formato SQL e il versionamento viene praticato su questo file testuale. In questo modo, il diff tra versioni può essere effettuato in maniera testuale analogamente a quanto si fa per il codice sorgente. Le varie operazioni danno luogo a differenze di questo tipo:
- Un insert dà luogo a una nuova riga insert into ... nel dump.
- Un delete dà luogo alla cancellazione di una riga insert into ... nel dump.
- Un update dà luogo alla sostituzione di una riga insert into ... nel dump con un'altra riga dello stesso tipo (con valori diversi).
Per developer.it, i comandi che effettuano il dump e il commit del DB Sqlite sono:
svn update data/developer.dbdump && ssh user@developer.it "echo .d | sqlite3 /data/developer.it/developer.db" > data/developer.dbdump && svn commit data/developer.dbdump