Posts Tagged ‘VS2010’

h1

TFS 2010 Teambuild | Mythen zum Gated Check-In

September 30, 2011

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.

clip_image002
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?!

clip_image002[4]
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.

Advertisements
h1

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

Juli 3, 2011

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.
image

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. image
    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”
      image
    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:

image
Rechte Maustaste an einem fehlgeschlagenen “Gated Build”

image
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.

h1

VS 2010 Extensions – meine Favoriten

Juni 30, 2011

Ich hatte ja schon mal vor langer Zeit einen beliebten Artikel zu Visual Studio Erweiterungen. Jetzt ist wieder viel Zeit vergangen und es ist inzwischen deutlich komfortabler geworden, dank des Extension Managers in Visual Studio. Hier also eine kleine Auflistung in verschiedenen Kategorien.

Ohne geht gar nicht:
Sollte man haben:
Kann man mal probieren und ist ganz nett:

Viel Spaß beim installieren und ausprobieren. Bis auf ReSharper sind alles kostenlose Extensions für Visual Studio 2010.

h1

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

Juni 30, 2011

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.

 image
Team Project Settings > Source Control

 image
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.