Mikael Deurell : TFS

Nya grymma Power Tools för Team Foundation Server

mikaeld — Wed, 23 Apr 2008 22:25:00 GMT

Jag får alltid en känsla av mini-julafton när det släpps nya Power Tools... Nästan som den där känslan av att vara 10 år och få ett morgonpaket med JetPac till min gamla ZX Spectrum i min kärleksfullt hemstickade julstrumpa... Det vi hittar i strumpan denna gång är:

TFS Manager - Ta ut statistik över användare och en massa annat, hälsorapporter (Och glöm mina gamla sura SQL- och powershelltweaks! :-))

Work Item Templates - I ny förpackning integrerad i Team Explorer under aktuellt Team Projekt

Och möjligheten att scripta team project skapandet (från PowerShell såklart), och mer, och mer... Och det är inte omöjligt att ni hittar JetPac där någonstans bland alla de andra härligheterna... Om ni bara letar...

Ni hittar downloaden här!

Ny version av Attrice Sidekicks för TFS

mikaeld — Wed, 16 Apr 2008 23:38:00 GMT

Attrice släppte för några dagar sedan version 2.1 av Sidekicks. Lysande! :-)

Hur många gånger har ni saknat "Check Out For Edit" för Build Types direkt från Team Explorer?

Rosario April CTP, redo för en rejäl överraskning?

mikaeld — Fri, 11 Apr 2008 12:36:00 GMT

Jag har bara en sak att säga; "NI VILL INTE MISSA DENNA OM NI HAR NÅGOT SOM HELST INTRESSE AV FRAMTIDEN FÖR VSTS/TFS!".

En frustererande sak med mitt jobb är att jag inte får prata om riktigt allt som kommer i nya versioner av VSTS/TFS, men äntligen kan jag visa er istället! :-)

Ladda ner! Återkommer med mer info kring denna CTP, var så säkra!

TFS tool för att hämta ut användare från Team Foundation Server

mikaeld — Fri, 14 Mar 2008 17:50:00 GMT

Hur kan vi få en överblick av hur många användare vi har i TFS? Jag skrev tidigare om lite SQL man kan köra för att få en inblick i detta. En annan variant är att iterera igenom alla Team Projekt och gå igenom alla TFS grupper, användare i alla roller som har användare i alla roller som har användare i alla. I alla.. I alla... Jalla jalla... Ja ni fattar... En härlig rekursiv snurra... Jag var tvungen att göra en första spike för att testa konceptet och nu är den klar.

I nästa version kommer den att paketeras i en powershell cmdlet men som det är nu är det en consolapp som skriver antalet unika användare till en logfil. Ni hittar binärer och all källkod på codeplex. Kom gärna med tips på förbättringar, det är en spike så det går att skruva rejält!

How Microsoft does Scrum and CI

mikaeld — Sat, 08 Mar 2008 12:14:00 GMT

En inte helt ovanlig fråga jag får när jag är pratar om Scrum, Crystal Clear, CI, VSTS, TFS och annat ASD relaterat med våra kunder och partners är:

- "Men Micke, hur gör ni själva?"

Microsoft har under de senaste åren blivit en härlig Scrumfabrik. Över 30% av alla projekt som körs internt på Microsoft använder Scrum som bas och när vi pratar ASD är Scrum och Continuos Integration de delar vi driver hårdast. Det härliga med att vi använder våra egna produkter (TFS) internt är att våra features i VSTS/TFS riktas mot de områden vi tycker är viktigast, och kopplat till detta ge teamen/våra kunder ett verktygsstöd som rockar! Men vad använder vi mest? Microsoft Research har gjort en intern undersökning kopplat till användandet av ASD (Agile Sofware Development) och ni kan ladda ner den här. Lite härlig helgläsning!!! :-)

Hur många TFS-användare har vi... Egentligen?

mikaeld — Thu, 31 Jan 2008 10:55:00 GMT

Även om vårt stöd för att ta ut användarstatistik ur TFS kan behöva några iterationer till för komma på fötter så finns det hjälp att tillgå. Min rockande kollega Christian Nielsen (varför har du ingen blogg?) på Microsoft Consulting Services har legat på Brian Harry som en hök och tagit fram rapporter som kan köras över tid för att kunna se trender i TFS användandet. I botten är det lite fancy sql mot Team Foundation Server, så om ni vill göra det själva är det ingen hjärnkirurgi. Eller... Använd några timmar av Christians hjärna via MCS och ni får allt paketerat och klart! Bra jobbat kompis!

Version Control... Från mossiga diskussioner till handling!

mikaeld — Mon, 08 Oct 2007 13:54:00 GMT

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:

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!

Rykten från korridorerna... TFS 2 TFS Sync tool...

mikaeld — Tue, 02 Oct 2007 14:34:00 GMT

En av de stora utmaningarna vid införandet av TFS i en organisation är hur man skall partitionera team projekt. Hur funkar det egentligen i en organisation där man har lika mycket förvaltning som nyutveckling? Ett stort övergripande teamprojekt för alla system och en massiv användning av areas/iterations för att få en tillräcklig upplösning på aktuella work items?

Eller skall vi ha ett specifikt projekt för varje team som jobbar tillsammans?

Eller kanske ett team projekt för en logisk gruppering av olika system?

Internt använder vi ett team projekt för hela Visual Studio (C++, C#, Foxpro, Express etc.) och branchar till ett nytt teamprojekt vid varje ny release (Whidbey, Orcas, Hawaii), och har en härlig lista med areas för att kunna hitta rätt... Men... Vi är ett otroligt stort produktbolag... Och hur våra servicing brancher (med sp, hotfixar etc) ser ut, vågar jag inte ens börja beskriva. Men vad händer med vår Sharepointportal? En för alla projekt? En för alla system och kataloger för alla ingående delar? Rättigheter? Buggar i ett system som på vägen visar sig höra till ett annat teamprojekt?

Svaret är givetvis, det beror på... Min utgångspunkt när jag personligen rekommenderar är försöka hålla ihop team projects baserat på vilka människor som jobbar ihop istället för på vilka system som ingår. På detta sätt kan vi anpassa processmallar för teamet och förbättra dessa baserat på det man lär sig i ingående iterationer samt ge maximal flexibilitet till teamet. Men... Om det viktigaste för organisationen är en enhetlig processmall (hemska tanke), att smidigt kunna logga buggar på en övergripande nivå utan att behöva överföra workitems från mellan olika team projekt och mappa detta mot en förvaltningsorganisation mer än en nyutvecklingsavdelning... Då är det "team partitionerings" rådet ganska kasst...

Förr eller senare knäcker någon... SYNKRONISERINGSTANKEN! Vilket stöd finns? Hur svårt kan det vara... Egentligen?

Internt vet jag att det är ett projekt som kommit ganska långt som är inriktat på att erbjuda en Windowstjänst som kan synca kod och workitems mellan olika TFS team projekt (TFS Sync Tool). Detta kommer att göra världen lite vackrare för er som väljer en modell där ni har många teamprojekt som måste synka workitems eller annat...

Jag återkommer med mer info!

Team Foundation Server Best Practices Analyzer... Äntligen!!!

mikaeld — Sat, 29 Sep 2007 16:27:00 GMT

Äntligen har vi släppt Team Foundation Server Best Practices Analyzer! Mina erfarenheter av betaprogrammet där man var tvungen att registrera sig med en massa härliga formulär och motiveringar, är att detta verktyg ROCKAR och sparar in mängder av timmars felsökning. Har ni en TFS installerad? Kör verktyget asap! Har ni en nervös, lätt inkompetent ansvarig för er TFS som inte kan skilja på en byte och en påse navelludd? Få honom att köra verktyget och hjälp honom bli en hjälte! Tillsammans med detta släppte vi även lite annat smått och gott i Visual Studio 2005 Team Foundation Server Power Tools men TFSBPA är det som får min röst! Det som hänger med är:

Team Foundation Power Tool Commands

Process Template Editor

Custom Check-In Policy Pack

Test Tools Build Task

Team Foundation Server Best Practices Analyzer

Work Item Templates

Detta är ~~nästan~~ lika schysst som http://www.gooh.se/... #%"#& vad bra!!!

So, Get Latest Version is broken? :-)

mikaeld — Fri, 17 Aug 2007 14:45:00 GMT

Jag missar aldrig en post på Gray's Matter (Som är en blogg precis så som bloggar borde vara och inte nån "%#&&"# akademisk minutiöst genomtänkt artikel [ok, Tess är undantaget]). Imorse när jag läste senaste inlägget skrattade jag så jag höll på att dö! Been there, got the t-shirt.... Såhär i efterhand önskar jag att jag inte hade lindat in mitt svar så mycket som jag gjorde... Ärlighet varar längst... Kolla http://graysmatter.codivation.com/BoardroomConfessionsWithLoveEpisode01.aspx. Eller varför inte denna: http://graysmatter.codivation.com/GuessTheCoder.aspx...

Och om ni undrar vilka sessioner jag skall köra på årets Tech-Ed i Barcelona så hittar ni dom här!

Ny "Team Development with TFS" bok från P&P - Och, ja den är gratis!

mikaeld — Mon, 06 Aug 2007 23:00:00 GMT

En lyckad TFS implementation har mycket att göra med utbildning... För att få TFS att rocka i projekten krävs det enligt mina högst ovetenskapliga empiriska studier:

1. Att man har minst en person i varje team som kan hantera TFS på ett lite råare sätt än "mes-GUI" mode.
2. Att man inte gör saker krångligare än vad de är ("vi är väääldigt speciella och måste ha branches i fem nivåer...")
3. Att teamet läser in sig på hur TFS fungerar och hur detta effektivt kan mappas mot företagets arbetssätt

Ni bör inte:

1. Ha en centralt placerad, mindre begåvad, nervös människa bakom TFS spakarna som sköter alla merges (RI/FI) och får spel varje gång det poppar upp en varning eller ett fel.
2. Ähhh, struntar i den. Undvik bara punkt 1 så är det lugnt!

Vilken tur att våra hjältar på P&P har släppt en lysande bok som ni gratis kan ladda ner (gör det pronto!) med:

- Branching Guidelines
- Project structures (ASP.net / .not / .net)
- PM
- Reporting

Lysande! Ladda ner från codeplex!

Följ best practices kring RI/FI i TFS och hamna där det är riktigt hett om fötterna...

mikaeld — Thu, 24 May 2007 23:05:00 GMT

Vi har för ett tag sedan publicerat lite guidance för hur vi rekommenderar er att hantera branchning/VBLr (Virtual Build Labs)/Feature teams i TFS. (http://www.codeplex.com/BranchingGuidance). Det underbara med detta är att vi för en gångs skull kan ställa teamen på tårna, gå från en Main med dålig stabilitet och sjukt fet testfas och istället låta feature teams eller delar av projektet få en egen branch (som de är ansvariga för att testa och bara merga med main när den är ok) och sedan göra en RI (trycka saker från vår ostabila branch till main efter ha passerat en Quality Gate) eller FI (trycka ut nya features från main till vår branch). Vad vi beskriver är egentligen hur vi jobbar internt i DevDiv, eller mer riktigt, hur de flesta sunda mjukvaruproducerande företag jobbar för att få upp kvalitet på main och ställa teamen på tårna...

Det tråkiga är att om ni följer instruktionerna och bestämmer er för att sätta upp ett sort antal VBLr så kommer ni med största sannolikhet att hamna i trubbel... Dags att vara ärlig och lägga bort käcka marknadsföringsfloskler...

Detta kommer att bli bättre i Orcas releasen och förhoppningsvis vara helt fixat (no #&"&%#) i Rosario. Men... Sanningen är att idag är kvaliteten på TFS för att hantera ett stort antal VBLer (Mycket som skall mergas) långt ifrån tillräcklig. Detta gör att om ni sätter upp många VBLr enligt vår best practices i dokumentet ovan kommer ni springa på problem... Lite av "Följ vår best practice och hamna i ett ställe där det är väldigt hett...". Problemet ökar linjärt med antalet VBLr... Detta gör mig otroligt ledsen...

Mina tips är:
- Kör cherry-pick merges istället för att köra en fet RI/FI på allt tills dess att TFS är uppe på banan
- Sätt inte upp för många VBLr, håll det till ett absolut minimum.
- Ha en resurs som inte är rädd för att göra lite hardcore TFS admin ala consol-mode och som inte får svettningar vid kända mergeproblem.
- Var inte rädd för auto:AcceptTheirs vid resolve
- Försök att sprida ut RI/FI så att inte varenda team skall köra en RI den sista dagen innan release (vilket ändå kommer att hända ;-))

Ett av de första problem ni kommer att råka ut för är det underbaraste felmeddelande jag sett i modern tid. Försök att förklara vad som hänt här:

TF14087: Cannot undelete “%0- insert your file name here” because not all of the deletion is being undeleted.

För att fixa gör en:
- tf dir itemspec /deleted (Kolla vilka filer som inte kan undeletas)
- Kör en manuell tf undelete /newname:name itemspec

This one is called Stella was a diver and she’s always down...