Microsoft Visual Studio ALM Days 2011 (ehemals TeamConf)

Vom 23.-25. November findet die TeamConf 2011 unter neuem Namen ALM Days in München statt. Wie in den vergangenen Jahren werden hochkarätige Vorträge und Speaker u. a. Sam Guckenheimer (Microsoft) und Brian Harry (Microsoft) vor Ort sein.

Auch wir von der T-Systems Multimedia Solutions GmbH sind mit Vorträgen rund um das Thema ALM vertreten. Sebastian Wagner, Projektleiter und Daniel Kubis, Software Architekt bei der MMS, berichten über Erfahrungen bei der Einführung des TFS 2010 und die Einbindung in die Unternehmensprozesse bei der T-Systems MMS. Daniel Kubis stellt am Technical Day Erfahrungen und Best Practices mit TFS Teambuild und Sebastian Wagner best practices bei der SharePoint Entwicklung mit TFS 2010 vor.

Hier finden Sie die Agenda, das begleitende Workshop-Angebot und das Anmeldungsformular:
www.teamconf.de

TFS 2010 Teambuild | Mythen zum Gated Check-In

Ich hatte ja schon vor Tagen einen Artikel über Gated Check-In aus Entwicklersicht geschrieben und versucht ein paar Mythen auszuräumen. Trotzdem kommen immer wieder neue Fragen und Fragezeichen auf.

Ein Kollege wollte gerne eine Check-In Policy, die ein “Get Latest” vor dem Check-In simuliert, weil sie das Gefühl hatten, dass dank des Gated Check-In Code verloren geht. Das konnte ich nicht glauben und war auch der Meinung, das so eine Check-In Policy völliger Quatsch ist. Beim Check-In wird der Entwickler sowieso gezwungen bei Konflikten einen Merge am Client zu machen. Wenn die Konflikte behoben sind kann er den Check-In vornehmen und der Gated Build würde den Code bei erfolgreichem Build auch in den TFS Server einchecken.

Was ist also der Grund für den Policy Wunsch bzw. der Grund für den “verlorenen” Code? Nehmen wir mal an zwei oder mehr Entwickler ändern genau an den gleichen Codezeilen und versuchen nahezu zeitgleich einzuschecken. Bei jedem Entwickler wird auf seinem Client mit dem Stand der im TFS eingecheckt ist ein Merge vollzogen und kein Konflikt festgestellt. Der Code geht also an den Team-Build und reiht sich in die Schlange der Gated Builds ein. Siehe Abbildung 1.

Abb. 1: Gleichzeitige “Gated Builds” werden in Build-Queue eingereiht.

Wenn der Code erfolgreich gebaut hat, wird der Code des “schnellsten” Entwicklers an den TFS Server übergeben. Der nächste Gated Build kann aus der Queue durch der Build-Controller gestartet werden. Jetzt kann es passieren, dass der Gated Build schon am Anfang fehl schlägt, wenn kein “Auto-Merge” durchgeführt werden kann (weil ja die Entwickler auf der gleichen Codezeile Änderungen vorgenommen hatten). Das erwartete Verhalten ist also, dass folgende Builds aus der Queue immer nur nacheinander und nie zeitgleich ablaufen und dass bei Merge-Konflikten der Build fehlschlägt und der Entwickler erneut Clientseitig Mergen muss um einen weiteren Gated Build anzustoßen.

Jetzt haben wir aber das Phänomen, dass wie in Abbildung 2 zu sehen, die weiteren Gated Builds aus der Queue NICHT wie erwartet nacheinander Loslaufen sondern auf einmal gleichzeitig auf verschiedenen Agents?!

Abb. 2: Fehler? “Gated Builds” werden aus der Build-Queue gleichzeitig gestartet.

Hier liegt vermutlich das Problem. Jeder Build für sich ist auf dem Agent valide und geht erfolgreich durch und wird in den TFS eingecheckt. Wenn aber Änderungen an gleichen Codepassagen vorhanden sind, kann es passieren, dass Code verloren geht?! Wer hat ähnliche Phänomene und kann Tipps geben.

In verschiedenen Foren haben wir ähnliche Probleme entdeckt, aber noch keine Lösung. Wir nutzen nur einen Build-Controller, der wiederum sehr viele Agents verwaltet. Es ist auch schon häufiger aufgetreten dieses Problem.

Fazit: Es würde definitiv keine Check-In Policy helfen, die “Get Latest” vor dem Check-In erzwingt, denn Merge Konflikte muss der Entwickler sowieso manuell lösen und das geht nur gegen den Code der im TFS eingecheckt ist. Würde die Queue im Falle eines Gated Check-In auch wie erwartet arbeiten (also alle Builds sequentiell) würde aus meiner Sicht auch nie Code überschrieben/verloren gehen.

Gated Builds / Gated Check-in mit TFS2010 / VS2010 aus Sicht eines Entwicklers

Seit TFS 2010 gibt es die Möglichkeit einen “Gated Check-in” zu erzwingen. Dadurch ändert sich das Handling für den normalen Entwickler ein bisschen, denn der TFS checkt den Code eines Entwicklers nur dann ein, wenn der “Gated Build” erfolgreich war.

Wie der normale Workflow ist habe ich hier für alle Entscheidungen und Fälle bei einem Gated Check-in zusammengefasst:

• Unmittelbar vor dem Einchecken:

1. "Get Latest", damit verhindert man ggf. Check-in Konflikte.
2. Rebuild Solution, danach ggf. Warnings, Fehler entfernen
3. UnitTests durchführen, evtl. Fehler beseitigen

• Änderungen Einchecken:

1. Kommentar zum Check-in abgeben
2. Mit Work Item verknüpfen (im Idealfall mit einem Task, Bug und diesen auf Resolved stellen)
3. Mit OK wird der verbundene “Gated Check-in” angezeigt. Hier hat der Entwickler zwei Möglichkeiten (Änderungen lokal beibehalten, oder nicht beibehalten):
4. 
5. Abhängig ob man die Änderungen lokal beibehalten oder nicht beibehalten hat, muss man je nach Erfolg des Builds verschiedene Schritte durchführen:

• Nach erfolgreichem Build ("Preserve my Pending Changes"/Änderungen lokal beibehalten angewählt):

1. "Reconcile Workspace" – gleicht lokalen Stand mit dem auf dem Server ab
2. "Undo Pending Changes" – macht Checkout von nicht geänderten Dateien rückgängig
3. Jetzt hat man lokal wieder den letzten Stand aller Sourcen und hat keine Dateien mehr ausgecheckt.

• Nach erfolgreichem Build ("Preserve my Pending Changes"/Änderungen lokal nicht beibehalten abge-wählt):

  1. "Get Latest" – letzten Stand abrufen, da vorher ein Shelve + undo pending changes lokal gemacht wurde

• Nach Fehlerhaftem Build ("Preserve my Pending Changes" angewählt):

1. ggf. “Get Latest Version” oder “Get Specific Version”
   
2. Problem beheben, Fehler fixen, Tests fixen
3. Erneut einchecken und warten

• Nach Fehlerhaftem Build ("Preserve my Pending Changes" abgewählt):

1. Stand "unshelven" um lokal wieder den Fehlerhaften Stand zu haben.
2. Problem beheben, Fehler fixen, Tests fixen
3. Erneut einchecken und warten

Man kann unabhängig ob man die Änderungen bei einem Gated Check-in lokal beibehält oder nicht prinzipiell weiterarbeiten. Vielleicht bietet es sich trotzdem an den Gated Build abzuwarten und solange keine weiteren Änderungen vorzunehmen. Wenn man sich mit den ganzen Workflows vertraut gemacht hat und die Mechanik verstanden hat, wird man feststellen, dass es durchaus möglich ist ganz normal weiterzuarbeiten und sich von der ganzen “Gated Build Problematik” nicht weiter einzuschränken. Es ist also meiner Meinung nach ein “Mythos” dass Gated Check-in eine Blockade oder Bremse bei der Entwicklung darstellt.

Dinge wie “Reconcile” oder “Unshelve” kann man an verschiedenen Stellen machen. Die beste ist eigentlich im “Build Explorer” an einem bestimmten Build mit rechter Maustaste:

Rechte Maustaste an einem fehlgeschlagenen “Gated Build”

Rechte Maustaste an einem erfolgreichen “Gated Build”

Was alles bei einem Gated Check-in Workflow passieren soll (nur Compilieren, oder auch UnitTests usw.) entscheidet letztendlich der Buildmanager. Was man dort alles machen und optimieren kann werde ich in einem weiteren gesonderten Post beschreiben.

TFS Check-In Policy | Nur auf “aktive” Work Items einchecken

Ein Kollege fragte heute, wie er seine Entwickler dazu bekommt nur auf aktive Work Items im TFS einzuchecken. Ja dafür gibt es eigentlich eine ganz passable Möglichkeit in dem man die “Work Item Query Policy” verwendet.

 
Team Project Settings > Source Control

 
Check-in Policy > Add > Work Item Query Policy

Jetzt noch eine entsprechende Team Query auswählen und fertig. Jetzt können die Entwickler nur noch Work Items auswählen, die durch die Query gefunden werden. Sinnvoll ist dann z.B. “All My Active WorkItems” als Query anzulegen. Es kann aber auch Sinn machen, dass ein Entwickler nur WorkItems aus einem aktuellen Sprint wählen kann. Auch dass kann man ja durch anpassen der Query entsprechend erreichen.

Wo kommt nun diese Check-in Policy her? Jeder Teilnehmer des Team Projektes muss in seinem Visual Studio die folgende Extension installieren: Team Foundation Server Power Tools March 2011

Der Projektadmin kann entsprechende Queries anlegen oder modifizieren und auch die Check-in Policies administrieren.

Microsoft Process Template (MPT) mit TFS2010

Microsoft hat auf Codeplex ein Template zur Verfügung gestellt, dass für Visual Studio Team System 2008 (VSTS) eine hierarchische Abbildung von Work Items ermöglicht. Mit TFS 2010 wird die Hierarchie nun aber von Haus aus unterstützt und somit ist mit Sicherheit eine Reimplementierung dieses Templates notwendig. Zur Zeit steht aber weder dieses Template auf Codeplex zur Verfügung noch, dass es Infos zu diesem Template im Zusammenhang mit TFS 2010 existieren.

Wir haben dieses Template etwas abgewandelt eingesetzt und standen jetzt aber vor dem Schritt, wie wir dieses weiter unter TFS 2010 supporten, bevor die Projekte auslaufen oder auf neue Templates migriert werden. Die gute Nachricht vorweg, wir haben einen Weg für uns gefunden, den zugehörigen Dienst weiterhin funktionstüchtig zu halten. Dazu hier ein kurzer Abriss zu den notwendigen Schritten:

1. Es bietet sich an die Solution mit Visual Studio 2010 zu öffnen und die verwendeten Referenzen auf den TFS neu zu setzen (von Version 9.0.0.0 auf 10.0.0.0)
   
   Das gilt für das Projekt “MptCodeLibrary” und “Test.UnitTest”
2. Ein Recompile des Codes liefert jetzt einige Warnungen von denen man einige sehr schnell abarbeiten kann. Folgende Änderung sollte man auf jeden Fall durchführen:

      1: TeamFoundationServer tfs 

      2:   = TeamFoundationServerFactory.GetServer(serverName)

   ersetzen durch:

      1: TfsTeamProjectCollection tfs 

      2:   = TfsTeamProjectCollectionFactory.

      3:     GetTeamProjectCollection(new Uri(serverName));

3. In der App.config müssen die WCF Einstellungen an 2 Stellen angepasst werden, weitere Infos findet man auch hier und hier: 

   

   basicHttpBinding zu wsHttpBinding 
   und wsHttpBinding muss  an der entsprechenden Stelle noch konfiguriert werden:

      1: <bindings>

      2:     <webHttpBinding>

      3:     ...

      4:     </webHttpBinding>

      5:   <wsHttpBinding>

      6:     <binding name="noSecurity">

      7:       <security mode="None"/>

      8:     </binding>

      9:   </wsHttpBinding >          

     10: </bindings>

4. Es muss jetzt die URL der Collection zu den Team Projekten in die App.config eingetragen werden.

      1: <teamServerSection>

      2:  <teamservers>

      3:   <teamserver servername="http://tfs:8080/tfs/default" />

      4:  </teamservers>

      5: </teamServerSection>

5. In der TeamFoundationFacade muss in einer Methode die Sid ermittelt und mit übergeben werden (alter Code wurde auskommentiert):

      1: public void SignupForReceivingEvent(string serverName, 

      2:     string receiverPath, string filterExpression)

      3: {

      4: ...

      5:   try

      6:   {

      7:     //eventEndpoint.SubscribeEvent("Sid is ignored", 

      8:     //  "WorkItemChangedEvent", filterExpression, delPreference);

      9:     // get sid from current user

     10:     string sid 

     11:         = System.Security.Principal.WindowsIdentity

     12:         .GetCurrent().User.Value;

     13:     eventEndpoint.SubscribeEvent(sid, "WorkItemChangedEvent", 

     14:         filterExpression, delPreference);

     15:   }

     16: ...

     17: }

6. Jetzt sollte man den Stand erreicht haben, dass wieder Events am Service ankommen, doch leider werden sie noch nicht richtig bearbeitet. Dazu muss eine weitere kleine Anpassung in GlobalListBuilder erfolgen (in diesem Fall wurde nur für eine Collection eine Unterstützung eingebaut!!!):

      1: private string DeriveTfsServerName(

      2:   XContainer workItemChangedEvent)

      3: {

      4:   ...

      5:   Uri artifactMoniker = new Uri(displayUrlElement.First().Value);

      6:   //IEnumerable<TeamServerConfiguration> teamServers 

      7:   //   = from teamServer in mptConfiguration.TeamServers where ...

      8: ...

      9:   //if (teamServers.Count() <= 0)

     10:   //    throw new MptException("Could not determine the TFS...

     11:   return artifactMoniker.Scheme + "://" 

     12:          + artifactMoniker.Authority 

     13:          +"/tfs/defaultCollection";

     14: }

7. Jetzt sollte sowohl der Dienst als auch das TFS Event empfangen und bearbeiten funktionieren.

Ziel ist es nach der Migration des TFS 2008 auf TFS 2010 die Projekte mit dem MPT Template weiter zu unterstützen, aber perspektivisch auf ein neues Template zu migrieren. Dazu wollen wir die Tools von der TfsIntegration Plattform verwenden. Vielleicht kann ich ja dazu in den kommenden Wochen auch noch Erfahrungsberichte veröffentlichen.