Introduzione all'uso di Branching & Merging strategies nei centralized source control

1. Branching & Merging
strategies (with TFS) 28 Aprile
2016
Sponsored by
Come accelerare i tuoi rilasci a costo zero

2. Sponsor

3. Presentazione
• Igor Antonacci
• DevOps Engineer & System Architect @ Fresenius Medical Care
• Co-Fondatore di DotDotNet e GetLatestVersion.it
• Twitter: @bitbreaker
• Facebook: fb.me/igorantonacci
• Email: igor@igorantonacci.me

4. Agenda
• Introduzione
• Nomenclatura
• Perchè ...Strategies –
«Sto adottando la strategia giusta per il mio prodotto / Team / ciclo di sviluppo?»
• Strategy #1 – Main Only
• Strategy #2 – Release Isolation
• Strategy #3 – Development Isolation
• Strategy #4 – Development and Release Isolation
• Strategy #5 – Servicing and Release Isolation
• Strategy #6 – Servicing, Hotfix and Release Isolation
• Strategy #7 – Feature Isolation
• Strategy #8 – Code Promotion
• Branching and Merging Anti-Patterns
• Conclusioni
• Reference

5. Introduzione – 1
Context
• Centralized Source Control – TFVC SOLO come esempio
• Team con più di un membro (2 è sufficiente)
• Prodotto/i (Software) da consegnare (artifacts)

6. Gli Attori
Team members Project
Da consegnare in
tempo!
Utenti FELICI!
Codebase
Team

7. Problematica da risolvere
• Processo di sviluppo consolidato
• Design  Sviluppo  Test  Deploy
• Uno o più Prodotti Software
• Versioni differenti (prossima, in rilascio, in manutenzione)
• Clienti diversi / diverse personalizzazioni
• Uno o più Team
• «allocati» su Feature / Versioni differenti
• UNICA CODEBASE
NON ESISTE ALCUNO studio indipendente sulla correlazione tra
Processo di Sviluppo e Metodologia di Branching

8. Perchè ...Strategies
• Approccio empirico al problema
• Attaccare il «nemico» facendoci il meno male possibile
La strategia si applica a tutti i campi in cui per raggiungere l'obiettivo sono necessarie una serie di
operazioni separate, la cui scelta non è unica e/o il cui esito è incerto.
(cit. Wikipedia – Strategia)

9. Goal
• Gestire il lavoro concorrente di UNO o più Team sulla stessa
codebase
• Isolare il rischio introdotto da diversi insiemi di modifiche alla
codebase
• Fare delle istantanee della codebase al fine di gestire successivi
cambiamenti isolati (es. Branch per Release, Personalizzazioni
ecc.)

10. Nomenclatura
Termine Descrizione
Development Branch Branch che contiene i cambiamenti (alla codebase) per la prossima versione
Forward Integrate (FI) Merge da un ramo padre ad uno figlio
Reverse Integrate (RI) Merge da un ramo figlio ad uno padre
Hotfix Cambiamento necessario a riparare un bug «bloccante» o un problema che impatta
l’intero sistema.
Main Branch E’ il branch «che congiunge» il ramo di sviluppo con quello di rilascio.
Release Branch Branch dove confluirà il codice in preparazione per una specifica versione
Release Vehicle Il modo in cui il prodotto viene «rilasciato» al cliente (Hotfix, Major Release, Service Pack
etc.)
Service Pack (SP) Un insieme di hotfix e funzionalità per una versione precedente del prodotto

11. Strategy #1 – Main Only

12. Strategy #2 – Release Isolation

13. Strategy #3 – Development Isolation

14. Strategy #4 – Development and Release
Isolation

15. Strategy #5 – Servicing and Release Isolation

16. Strategy #6 – Servicing, Hotfix and Release
Isolation

17. Strategy #7 – Feature Isolation

18. Strategy #8 – Code Promotion

19. Branching and Merging Anti-Patterns
• Merge Paranoia – evitare di fare Merge a tutti i costi
• Merge Mania – Merge, Merge, Merge … come se piovesse 
• Big Bang Merge – Merge UNA VOLTA per «TUTTI» alla fine della fase di sviluppo
• Never-ending Merge - Merge continuo…
• Wrong-way merge – Fare il Merge di una feature sul ramo di una versione PRECEDENTE
• Branch-mania – come Merge-mania, ma per il Branch
• Cascading Branches – Branch che non confluiscono mai nel branch padre
• Mysterious Branches – Branch … e perché? 
• Temporary Branches – Branch effettuato per un cambiamento … ma che poi diventa un
workspace permanente
• Volatile Branches – Branch di uno o più Changeset anche se si trovano in uno stato unstable
• Development Freeze – SU LE MANIIIII
• Berlin Wall – Branch per dividere i membri del Team… non il loro lavoro

20. Conclusioni
• L’adozione di una Branching Strategy è NECESSARIA all’interno di
un Team
• La scelta della corretta Strategy non è sempre facile e non avviene
sempre al «primo colpo»
• Ogni Business / Dev Process ha delle caratteristiche uniche 
Create la Vs. Strategy … cum grano salis (cit.)

21. Reference
• Visual Studio ALM Rangers – Branching Strategies
(https://vsarbranchingguide.codeplex.com/)
• Branching Taxonomy – MS Research
(http://research.microsoft.com/apps/pubs/?id=209683 )
• Defining Your Branching and Merging Strategy
(https://msdn.microsoft.com/en-us/library/bb668955.aspx)
• Branch Folders and Files
(https://msdn.microsoft.com/en-us/library/ms181425(VS.110).aspx )