Vi kan plöja böcker med best practices och fundera på kammaren tills vi faller av pinn (modernt uttryckt Micke!), men när det kommer till kritan (inte en till... Då får du stryk Micke!) är det egentligen handling som får oss att att röra oss framåt, inte sega diskussioner kring ett runt bord på våning 18... Ett av de områden där jag upplever att vi överteoretiserar är när det skall etableras en plan för branchning i TFS. I min värld handlar source control om en sak... Isolering! Hur skall vi isolera källkod bundet till något som vi tycker är viktigt. Detta faller oftast ut i två områden (Prod och Dev). Och allt handlar om isolering (inte sånt man har i väggarna)...

Prod
Branching for Release
Inför en kommande release vill vi isolera en branch där delar av teamet kan driva jobbet med rent releasearbete (stabilize). När releasen är klar kan vi göra en RI (merge) tillbaks till Main. Detta gör att delar av teamet kan jobba som vanligt med Main medan releaseteamet kickar på releasebranchen och fokuserar allt jobb på att få denna klar i releasebart skick!

Branching for Maintenance
Vi har releasen klar och börjar snabbt som attan (Skärpning Micke!) jobba med hotfix 1 samt lägga upp en plan för hur alla våra hotfixar relaterar till SP1/SP2 etc. Här branchar vi ut från Main och lablar alla hotfixar och SPs på denna. Ifrån detta görs ingen RI till Main utan detta fixas med enkelt härligt manuellt arbete av teamet. Dessa kommer att leva under hela produktens servicing fas.

Dev
Features
Här skapar vi en branch från Main för att varje svajjig och skakig feature som vi bygger skall kunna leva sitt eget liv tills dess att den är stabil nog (har paserat en quality gate (84,5% code coverage, fxcop etc.) och kan mergas (RI) tillbaks till main. Detta isolerar skakiga features tills dess att de är stabila nog att mergas tillbaks till en stabil och ståtlig Main.

Teams
Här isolerar vi sub-team för att ställa dom på tårna och köra utan att de skall påverkas av breaking changes från andra team. Detta är väldigt likt Feature-branching ovan (och om det är ett team som jobbar på en specifik feature så är det samma sak)

Så... Om det enbart är en snubbe som jobbar med en feature kan han med gott samvete isolera sitt jobb med hjälp av sin Workspace och "%#& i branches. Så... Minimera antalet brancher baserat på isoleringsnivå. Brancha aldrig om det inte behövs denna typ av isolering. I 90% av fallet räcker det med en Main som branchar till Maintenance, som i sin tur lablas på hotfix, sp nivå... Strunta i håriga team/featurebrancher om de inte tillför något rent "isoleringsmässigt"...

Sen har vi ju hela resan med att brancha in dependencies från andra teamprojekt typ:

branch
Det härliga med denna karamell är att det är enkelt att visa hur detta rockar i praktiken men nästan omöjligt att beskriva med ett blogginlägg... Så! Istället för att teoretisera kring ett mossigt bord på arkitekturavdelningen på våning 18... Gå på en lysande dragning (for free!) kring hur man praktiskt jobbar med versionshantering med TFS. :-)

Anmäl er här!

Och som ett bevis på att jag blivit en medelålders famijegeek med en förverkligad radhusdröm köpte jag Bruce Springsteens "Magic" (och vågar erkänna det!) på freakin' iTunes och min ungdoms hjältar hamnade.... här!