User experience with Gated Check-in

When your TFS administrator has enabled the Gated Check-in feature you do not notice anything at first. However, when you check in files a new dialog box appears:

As you can see in the green-marked area the system has created a Shelveset where your changes are stored temporary. The changes are then being built using the build server. If the build is successful the changes are committed, otherwise they are not – which means your changes have not been checked-in.

The red-marked area shows a check-box that makes it possible to choose if your changes should be kept locally or not. Default is that they are preserved (as in the picture). More about this later.

In the Build Explorer a build that is triggered via a Gated Check-in is indicated by an icon showing up next to the build, see this image:

Above the green indicator (that I put there) you can see the icon. In the same place you see the clock icon if it is a scheduled build and so on.

When the build has been finished it either when all green and the check-in has committed, or an unsuccessful build was the result, and then the check-in was Rejected. As a user you notice this as a pop-up dialog is diaplayed. Below you can see the two different dialogs:

In the case where the Check-in has committed you probably want to make sure your workspace looks the same as what has been checked-in. You do this by pressing the Reconcile button. If you checked the “Preserve my pending changes locally” you the tool will sync everything for you. You can find the same functionality in the Build Explorer if you bring up the build log. There you can see if the check-in was Committed or Rejected and you can perform the Reconcilation from there as well.

Some important point to think about:
– Your changes are not Check-in if the build was not successful. A partially successful build is considered unsuccessful.
– If the build works locally, but not at check-in, one thing to look for is project reference problems

This feature will most certainly change the work behavior of the users. Make sure not to get any strange mis-behavior…

Good luck!

Advertisement

Configuring Gated Check-In

You have probably heard of a new feature in Visual Studio/TFS 2010 called Gated Check-In. The problem this is supposed to solve is the problem of broken builds – when a check-in makes the next build fail. In order to start using this feature you configure it in a certain way.

First you create a Build definition pointing out the solution you want to build in your “Gate”. You configure it to trigger at Gated Check-in as below.

Next important step is to chose when this build should trigger. This is configured under the Workspace tab in the Build definition. By pointing out a workspace location, whenever trying to check-in a file to that workspace a new build is triggered. In our current application we have three different solutions and each has its own build associated to it.

The functionality you get will make it impossible to check-in anything whenever this build is unsuccessful. Remember that a partially successful build, for example when some unit tests fail, will be considered an unsuccessful build.

I have also posted about the user experience Gated Check-in, se this post https://tomasscott.wordpress.com/2010/02/07/user-experience-with-gated-check-in/

Default setting might cause problems with TFS2010 Builds

Do you experience problems with your builds in TFS2010?
Unchanged builds that sometimes work and sometimes fail?

You might have problems with build agents. Build agents are used on build servers, and also on target machines to make it all work.
When you start up a new build, default is a build agent called *. So sometimes the build servers agent is used, and sometimes any other agent found on the network.
Of course this behavior is good if you have several identical build servers and want to take the first free one. However, if the other build agent is not a complete build server with Visual Studio installed, the build fails.

Here you can see a certain section of the Build definition with the default value of the build agent, which is the wildcard.

So be sure to point out a build agent that can be used to build your solution. This also makes the naming of you build agents important, so you can use the wild card in a good way. For example, call all build servers something with VSBuild, and you can use *VSBuild* as your build agent – and any free agent matching this name will be used.

In this image you can see that I have specified which build server to use.

Videointervju om Visual Studio 2010

Om ni följt bloggen så vet ni att vi kör ett projekt med Visual Studio och TFS 2010. Nu finns en videointervju med oss publicerad på Channel9, http://channel9.msdn.com/posts/buzzfrog/Lnsfrskringar-en-av-de-frsta-att-kra-Visual-Studio-2010-p-riktigt

På TechDays i Örebro 23-24 mars kommer ni ha möjlighet att höra mer om våra erfarenheter. Har just fått veta att vi blivit antagna som talare! Ytterligare en anledning att åka dit!?

Grattis SourceSafe-användare

I samband med lanseringen av Beta2 fick vi en hel del nyheter till livs gällande hur Microsoft tänkt sig paketeringen av Visual Studio och Team Foundation Server.

En glad nyhet för er som använder SourceSafe är att ni nu kommer kunna använda Team Foundation Server utan att det blir dyrare.
Verktyg för migrering från SourceSafe ingår givetvis.

Förutom en mycket bättre källkodshanterare får ni då också tillgång till workitems och bygghantering. Att kunna göra automatiska byggen vid varje incheckning eller varje natt samt att kunna koppla incheckningar till workitems är två funktioner ni kommer att älska! Se till att använda dem!

Hierarkiska workitems

En av de nya funktionerna i TFS 2010 är hierarkiska work items. Detta har verkligen varit efterlängtat – jag saknade det redan i 2005-versionen. Vad innebär då detta?

Jo, man har möjlighet att t.ex. bryta ned en stor uppgift i många mindre och relatera dem som Parent-Child. Detta är riktigt användbart. Man kan relatera olika typer av workitems, så t.ex. kan ett krav brytas ned i ett antal aktiviteter (Task) som skall utföras för att uppfylla kravet. Samtidigt relaterar man kravet till ett eller flera testfall för att enkelt kunna se vilka krav som är testade och inte.

I detta exempel har vi satt upp iterationsmål och sedan brutit ned dessa i aktiviteter som skall utföras för att uppnå målen. På detta sätt kan vi få en spårbarhet på aktiviteterna så att arbete leder i rätt riktning, dvs mot iterationsmålen – och inte åt fel håll.

Funkar det som utlovat då? Ja, det måste jag nog säga. Utmaningen är snarare att få alla att lägga upp workitems och jobba med ett workitem i taget och ha rätt storlek på aktiviteterna. Just nu känns det som att våra aktiviteter är lite för stora och därmed blir det lite luddigt var man faktiskt befinner sig, dvs hur långt är det tills man är klar. Jag tycker att jag kan teorin bakom, men har ändå svårt att lyckas utföra det…

Det skall bli spännande att se hur det går!

Att jobba distribuerat

Förra veckan körde vi workshopar i projektet. Eftersom vissa sitter i Östersund och andra i Stockholm körde vi med Office LiveMeeting och Communicator.

Till vår hjälp hade vi en RoundTable, en konferenstelefon med video som visar rummet i 360 graders vy. Sedan zoomar den in på den som pratar. Fungerar riktigt bra.

Vi kommer köra dagliga möten med Communicator – det känns som att tekniken är mogen, frågan är om vi deltagare är det.

VSTS2010-baserat projekt

På Länsförsäkringar har vi just startat upp ett skarpt projekt där vi kommer använda Visual Studio Team System 2010 och därmed även TFS och Lab Management. Allt som ett led i vårt deltagande i Microsofts TAP-program.

Jag kommer försöka rapportera på denna blog om intressanta saker inom projektet, men bara sådant som inte rör det vi faktiskt håller på att bygga – utan endast teknik- och projekt/metod-relaterade saker.

Vi har givetvis ett stort antal utmaningar kopplade till verktyget, vilket ni kommer att se framöver ifall ni följer denna blog. Några som kan nämnas:

– Distribuerat arbete, vi sitter i Stockholm och Östersund
– Testdrivet
– Jobba iterativt och agilt. Vi har inte sagt oss använda en specifik metod ännu utan tar bra saker här och var.
– Automatisera så mycket som möjligt avseende t.ex. test, deployment, byggen etc.

Spännande blir det – roligt – och helt säkert också jobbigt!

Problem vid installation av Lab Management

Efter att ha latat sig i hängmattan (med regnstället på 😉 under några veckor så var det dags att börja jobba igen.

Före sommaren försökte jag få igång Lab Management i en testmiljö som jag har. Det gick sådär. En hel del saker skulle fixas och jag fick inte färdigt innan semestern. Nu har jag tagit tag i det igen och hittat en brist i installationsmanualen. Varje fysisk host (Hyper-V maskin) behöver ha ett “External Virtual Network” som är knutet till nätverksadaptern. Detta går att läsa i följande blog:  http://blogs.msdn.com/lab_management/archive/2009/06/08/networking-basics-for-lab-management-part-i.aspx

Efter att ha fixat detta lyckades jag få igenom verifieringen som också beskrivs i nämn blogpost.

Just nu installerar jag virtuella maskiner i Hyper-V för att kunna prova det hela – spännande!

Labbet på väg upp

Snart har jag installerat ett kompelett labb med TFS 2010 samt Lab Management, byggserver mm.
Många installationer blir det, och gör man fel får man backa, vilket ofta innebär att blåsa maskinen och starta från scratch. Fördel är också om man har ett AD dit man kan joina maskinerna. Har du inte det, se till att skaffa ett – i alla fall om du skall ge dig på något annat än en singel-server installation.

Ett tips till er som försöker er på detta – läs instruktionerna noga – och följ dem noga. Betor är inte så förlåtande som släppta produkter är.

Eftersom Windows Server 2008 R2 är på väg ut så tänkte jag försöka köra på den. Vill ni köra in en TFS på den så läs följande Blog: http://blogs.msdn.com/dstfs/archive/2009/05/15/installing-tfs-2010-on-windows-server-2008-r2-rc.aspx

Skall ni köra Hyper-V och Lab Management – då är inte R2-versionen att tänka på vad gäller Hyper-V och SCVMM-maskinerna. Där gäller tidigare releaser än så länge.