TFS, Subversion och Scrum - våra migreringsefarenheter

I ett års tid har vi på Iteam haft en pågående migrering från Subversion SVN till Microsoft Team Foundation Server (TFS). På vägen har vi gjort en hel del viktiga lärdomar som kanske kan underlätta för andra som ska genomgå samma resa.

Strategiska val installation och arkitektur:

Börja med att installera TFS och sätt upp en LabCollection där ni testar er fram till vilken mall ni ska använda. Gör detta ordentligt och grundligt innan ni bestämmer er för det är väldigt komplicerat att byta i efterhand (läs mer om det nedan). Vi valde mellan följande mallar:
a) Microsoft Scrum 1.0 - vi valde denna på grund av att den är tillräckligt enkel att komma igång med och har färdiga fungerande mallar som är enkla att förklara även för kunder.
b) EMC Scrum For Team Systems 3.0 - vi utvärderade denna men den var för krånglig och krävde tjänster som krånglade samt att de bytte namnstandard mellan betaversion och skarp version vilket tvingade oss att uppgradera alla projekten
c) Microsoft Agile Template - denna var för enkel då den byggde mycket på att spara viktig data i Excelfiler som inte är integrerade i TFS.
Installera helst Application Tier på en virtuell maskin för att underlätta uppgraderingar då du enkelt kan ta en snap-shot inför uppdateringar eller större konfigureringsändringar etc
SQL Servern kan vara samma som ni redan använder i /Utvecklingsmiljön
Reporting Services kan ligga på SQL servern
Skapa externa DNS-namn till och se till att referera till dessa istället för de interna datornamnen eftersom länkar ofta kan bli interna annars:
a) tfs.companyname.se
b) reports.companyname.se
c) sharepoint.companyname.se
Använd tre olika service-konton för alla tjänster om ni har eller tänker dela upp instanserna mellan olika maskiner. Använd inte NETWORK SERVICE någonstans även om det finns bloggar som hävdar annorlunda.
Skapa ett Team Projekt för varje kund och ha skapa grupper i AD för kundens personal och lägg denna gruppen i Contributors för projektet i TFS

Strategiska val vid migrering SVN till TFS

Välj ett migreringsverktyg. Vi valde TimelyMigration SVN2TFS.
Se till att ha minst 8GB minne på servern som ska köra migreringen.
Installera ”Forward Compatibility Update for Team Foundation Server 2010” då produkten officiellt inte stöder TFS 2010 (än). Den är dock fullt kompatibel med hjälp av Forward Compatibility Pack.
Migrera SVN-koden först i testläge till LabCollection då det kommer strula en HEL del på vägen:
a) I SVN kan man göra en branch av ett helt träd utan att det ”kostar” någonting men i TFS görs detta annorlunda och i migreringen kommer dessa gigantiska branches äta upp minnet på servern som du använder.
b) Mappa därför alla branches både som ni har idag och som ni haft tidigare mot Labels. Detta är väldigt svårt att få rätt utan att köra en hel del Trial and Error.
Så fort ett fel uppstår avstannar hela processen och eftersom migreringen tar väldigt lång tid så se till att planera ett antal veckor för att hitta och lösa alla problem.
När ett fel har uppstått och du behöver ändra i konfigurationen (oftast lägga in en cloak eller label) så behöver du starta om processen från början. Även om det är praktiskt möjligt att fortsätta processen där den avstannade så är det inte att rekommendera då det oftast uppstår följdfel senare i migreringen som inte uppstår om du börjar om från början.
Gör först en torrkörning för att få passera alla viktiga fel i en LabCollection.

Viktiga skillnader mellan TFS och SVN

Branch och Tags är annorlunda än i Subversion. I SVN är en Branch bara en enkel kopia av trunken, en tag är också en kopia av trunken. I TFS är en branch en ”genväg” till trunken – dvs du kommer alltid behöva spara originaltrunken för att inte förlora historik! Nu är detta inget man behöver tänka på i vanliga fall eftersom det som händer när du tar DELETE i TFS så göms bara din nod, men om du någon gång skulle ta bort det teamprojekt där din kod någon gång har legat så försvinner all historik efter detta datum. Farligt!
Då konceptet kring Branch är annorlunda i sitt upplägg i TFS går det mycket lättare att merga skillnader fram och tillbaka mellan branches eftersom hierarkin är inbyggd i länkarna. I Subversion får man manuellt komma ihåg var saker hör hemma och vilka revisioner man vill överföra men i TFS sker detta automatiskt vilket är kanon.
I Subversion finns det en Repository Browser där man kan göra strukturella förändringar direkt i databasen utan att hämta alla ändringar till sin lokala hårddisk. I TFS måste alla förändringar göras på riktiga objekt, dvs du måste alltid hämta alla filer lokalt innan du tar bort dem eller flyttar på dem.
Det går inte att byta namn på ett Team Project när det väl är valt. Om du ändå vill byta namn genom att skapa ett nytt projekt och flytta källkoden till så får du inte ta bort ditt gamla projekt utan att kod-historiken försvinner (se punkt 1).
TFS är inbyggt i Visual Studio på ett annat sätt än TortoiseSVN och VisualSVN vilket är både en fördel och nackdel. Vissa verktyg från TortoiseSVN är bättre (Framför allt Diff verktyget). Den största fördelen med TFS för utvecklare är att man har möjlighet att koppla uppgifter/tasks/stories direkt till incheckningar vilket gör det lättare att rapportera sin status och för projektledare att få en överblick över nuvarande läge.
Den inbyggda buildmotorn i TFS är grym. Den klarar av att plocka ut hela din lösning från källkoden, pröva att kompilera, köra alla tester och publicera resultatet till er testserver eller bygga MSI paket automatiskt. Med lite justeringar går den även att få att uppdatera assemblyinformation till senaste revisionsnumret från byggmotorn vilket är väldigt bra för felsökning av releaser etc.
Blame/Praise heter Annotations
Nytt koncept finns för tillfälliga branches som heter Shelfsets vilket är smidigt att använda då man ska göra kortare tester som ska föras tillbaka till trunken eller om man ska justera saker i livemiljö utifrån en tidigare release och sedan föra tillbaka dessa ändringar till trunken.
En viktig skillnad för oss som utvecklar i .NET är att hela TFS motorn är möjlig att styra med webservices. Man kan dessutom prenumerera på händelser via webservices för att i kod få reda på när builds är klara, incheckningar sker för att logga eller automatisera andra flöden.
SVN är gratis och TFS kostar rätt mycket pengar med alla licenser och tid för uppsättning.
Färdiga rapporter finns tillgängliga för Burndown charts, release history, quality, bugs, etc. Väldigt smidigt för att automatisera delar av rapporteringsbehovet i projekt men också möjlighet att specialskriva egna rapporter med hjälp av Report Builder och Business Intelligence studio i Visual Studio.

Nu vet jag att många av ovanstående delar är möjliga med öppna alternativ så som Cruisecontrol etc och i efterhand kan jag inte säga att det har varit enklare att få Team Foundation Server att fungera jämfört med att sätta sig in i Cruise Control etc men den tekniska plattformen och de möjliga vägarna att fortsätta integrera med andra system är väldigt attraktiva i Team Foundation Server. Målet är ju i längden att ha en saftblandare som blinkar rött om någon har checkat in kod som inte kompilerar i byggservern – eller hur? ;)

Förhoppningsvis har du som läser detta fått en tankeställare som får dig att förstå att ett migreringsprojekt är inget man fixar på en kväll utan som kräver både planering och kunskap. Om du kör fast på vägen och vill ha hjälp i migreringen från SVN så kan du kontakta mig på Iteam eller vår partner som har varit ovärdelig hjälp i migreringen - Osiris Data.

Har du som läser andra erfarenheter, fördelar och nackdelar att dela med dig av är jag intresserad av att få kommentarer nedan!

Christian Landgren
2010-09-21