Archive for Juli 2011

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.