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?!
![clip_image002[4]](https://peroxide20.files.wordpress.com/2011/10/clip_image0024.jpg "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.
.NET Entwicklung & Architektur 