Copia-incollo da un thread di
XPUG-IT contributi da alcuni post tra cui uno di Piergiuliano Bossi.
Sul tema viene in aiuto
- il principio XP di semplicitá (quella che si raggiunge attraverso skill e padronanza, non quella che deriva dal banalizzare)
- il principio XP di flusso (fare una cosa in modo continuo e incrementale spinge a eliminare le inefficenze e lo spreco e risulta piu effecace, pensa ad esempio al refactoring continuo del TDD comparato a i grandi refactoring)
- il principio Agile: Gli individui e le interazioni prima dei processi e gli strumenti
Il punto e' avere una code base dove non hai bisogno di fare feature branching, dove il codice e' fluido e testato su molti livelli diversi in modo automatico, dove i conflitti sono minimi perche' ogni oggetto fa una e una cosa sola e la fa bene.
Alcune pratiche primarie:
- 1 unico repository per tutta l'azienza, un unico Trunk
- mai e poi mai dipendenze tra due trunk o repository diversi
- committare sempre sul trunk
- evitare branch
- committare solo codice potenzialmente rilasciabile in produzione
- tutti i rilasci sono compilati dal HEAD trunk e da codice sorgente (le librerie referenziate vengono ricompilate a partire dal codice - principalmente quelle realizzate o modificate internamente - dal HEAD, non vengono usate dll o binari di versioni fisse)
altre pratiche secondarie:
- check-in piccoli frequenti (ogni 15min-4h, o ogni pomodoro)
- latent code pattern
- feature togle (fowler)
- minimum informative increment (kent back)
- capacitá di rolback dell'ultima versione in produzione (occhio a modifiche che rompono la compatibilitá tipo cambio di schema del db, cambi a un protocollo client/serve, installazione di aggiornamenti di librerie/dipendenze esterne)
Queste pratiche descitte giá in una sessione dello IAD
2006, a partire da 3 anni dopo nel
2009 sono state documentate anche da Google, Flicker e Kent Beck e nel libro Continuous Delivery sono descritte come pratice che supportano appunto il rilascio. Cioé queste pratiche possono avere validitá in molteplici contesti con variazioni che dipendono dal tipo di prodotto software, tecnologia, requisiti e skill del team.
I vantaggi che portano:
- i check-in frequenti sul trunk a differenza dei merge dai branch i conflitti sono estremamente ridotti e quelli da risolvere manualmente sono rari; => notevole risparmio di tempo
- 1 repository 1 Trunk abilitano la semplificazione del ambiente di C.I. e il setup dei PC dei dev con un click => notevole risparmio di tempo
- committare solo codice rilasciabile in produzione + capacitá di rolback dell'ultima versione in produzione => senza questo é come avere un accelleratore senza freno, ora invece si puo correre di piu in sicurazza perché quando serve si puo sempre frenare !
- check-in piccoli frequenti + minimum informative increment + rilasci sono compilati da codice sorgente + rilasci frequenti => feedback rapido che individua eventuali problemi molto presto quando il costo di fixarli é ancora ridotto cioé maggiore qualitá con riduzione dei tempi