««« | »»»
Da Subversion a Git
Qualche tempo fa avevo descritto alcuni dei miei procedimenti per snellire le procedure di deployment sfruttando gli hooks1 di Subversion.2
Addio Subversion, buongiorno Git!
Da allora sono passato a Git. Dovendo quindi rivedere il processo ho cercato anche di sfruttare le potenzialità di questo software per il controllo di versione. Per chi non avesse mai sentito parlare di Git, diciamo che la differenza principale rispetto a Subversion è che il primo è un sistema distribuito, mentre il secondo è centralizzato3.
Perché Git?
La prima conseguenza è una distinzione molto più netta fra il controllo di versione e la pubblicazione delle proprie modifiche. In Subversion l’atto stesso di fare il commit implica la pubblicazione della nostra attività.
Per alleviare il problema potremmo fare il commit su un ramo privato per poi far confluire queste revisioni nel filone principale. Qui però ci scontriamo con un secondo limite di Subversion che è una minore robustezza nel riconciliare le revisioni. Subversion calcola le differenze al momento della riconciliazione, ignorando la genealogia delle due revisioni; Git applica le operazioni che hanno portato da una revisione all’altra.
Nuove possibilità
Comunque, il punto fondamentale in questo contesto è che in virtù della natura distribuita di Git, ogni repository fa storia a sé ed è anche per questo che può dialogare con altre repository, scambiandosi le revisioni. Possiamo quindi crearne più d’una, anche per un singolo progetto, ognuna con la propria configurazione e con gli hooks adatti. Facciamo un paio di esempi.
Il primo è quello in cui abbiamo due repository, una per lo staging e una per la produzione. Dalla mia macchina di sviluppo posso mandare le revisioni sull’una o sull’altra, oppure spedire le revisioni da staging a produzione: gli hooks penseranno al resto. In questo modo possiamo riportare in produzione la versione testata in staging o, se necessario, installare una modifica urgente direttamente in produzione.
Il secondo riguarda i filtri, che di solito uso per miniaturizzare CSS e JavaScript, che si applicano all’entrata e all’uscita, per così dire, dei contenuti dalla repository. In questo caso, le operazioni agganciate a questi filtri hanno senso solo nelle fasi di deployment, perché altrimenti ci porteremmo nel progetto le versioni miniaturizzate. Per fare questo basta attivarli solo sulla repository di staging ed entreranno in azione quando esporteremo da lì il sorgente.
Cos’è cambiato negli script, quindi?
Il principio di base non è cambiato e consiste nello sfruttare gli hooks messi a disposizione, in particolare quello di post-receive, che viene applicato quando una repository riceve delle revisioni da un’altra4. In aggiunta ho sfruttato la possibilità di definire dei filtri per scartare alcuni file, come gli unit tests o applicare delle trasformazioni ad altri.
Dato che però ora ogni repository fa storia a sé, non esiste più un elenco di tutti i progetti da controllare; poi, visto che Git non usa un numero progressivo per indicare la versione, le contorsioni per trovare il tag corretto. Per il resto la logica è invariata.
- Ovvero, script eseguiti in concomitanza di determinati eventi ↩
- Coda & Subversion ↩
- In realtà la questione è un po’ più complessa perché Git non nasce come VCS ma, di fatto, lo usano tutti per quello ↩
- È interessante notare che non esistono agganci alla creazione di un tag su una repository. Per farlo devo ricevere la versione taggata da un’altra repository ↩
Per proseguire
Commenti e trackback sono disabilitati.