TFS 2010: Gated Check-In und Scheduled Build kombinieren

Nach einem erfolgreichen Gated Check-In Vorgang wird an den Name des einzucheckenden ChangeSets das Flag ***NO_CI*** gehängt, um zu verhindern das ein Continuous Integration Build von diesem Check-In Vorgang ausgelöst wird. Leider hat dieses Flag auch Auswirkungen auf Scheduled Builds. Diese werden dann auch nicht mehr gestartet oder enthalten nicht mehr die neuesten Changesets.

In einem Team Projekt wird ein Gated Check-In als „Türsteher“ eingeführt, der das einchecken von nicht integrierbaren Source Code verhindern soll. Es soll damit vermieden werden, dass der tägliche VerteilungsBuild durch „schlechten“ Code fehlschlägt und der aktuelle Software-Stand nicht getestet werden kann. Die folgende Grafik beschreibt schematisch das Vorgehen:

GatedCheckvsNightlyAbbildung: Integrationsbranch mit Gated Check-In und Scheduled Build

Die Builds auf dem BranchDev“ sind Continuous Integration Build und laufen wie gewollt nach jedem Check-In an. Nach einem Merge von „Dev“ auf „Int“ (Integration-Branch) kommt der angesprochene „Türsteher“ zum Einsatz. Hier wird die Kompilierfähigkeit des Codes überprüft, bevor er eingecheckt wird. Eine ausführlichere Erklärung zur Funktionsweise von Gated Check-In Builds findet man z.B. auf den Seiten des MSDN.

Problembeschreibung:

Nach einem erfolgreichen Gated Check-In Vorgang wird an den Namen des einzucheckenden ChangeSets das Flag ***NO_CI*** angehängt. Dieses Flag soll verhindern, dass nach dem Eincheck-Vorgang eines Gated Check-Ins ein Continuous Integration Build gestartet wird, der das gleiche Changeset noch einmal übersetzen würde.

Leider hat dieser Standardmechanismus auch zur Folge, dass Scheduled Builds nicht mehr gestartet werden, wenn nur noch Changesets mit dem Flag ***NO_CI*** eingecheckt wurden. Für den IntegrationsBranch in der Abbildung trifft dies nun zu. Jedes Changeset wird erst durch den Gated Check-In Build verifiziert und dann getaggt. Somit funktioniert der automatische Verteilungsmechanismus durch den Nightly Build nicht mehr und unser Test-Zyklus kommt zum erliegen.

Lösung(en):

  1. Man könnte in der Build-Definition des Scheduled Build die Eigenschaft „Build even if nothing has changed since the previous build aktivieren. Dadurch würde der Kommentar nicht mehr ausgewertet und der Build immer gestartet werden. Hätte aber den Nachtteil, dass der Build auch dann läuft, wenn eigentlich keine Änderung eingecheckt wurde.
  2. Durch eine Anpassung in der Build-Definition kann erreicht werden, dass das Flag ***NO_CI*** nicht gesetzt wird. Die Änderung konzentriert sich auf das NoCIOption Property in der SyncWorkspaceActivity, dessen Value von „True“ auf „False“ gesetzt werden muss.

Eine sehr gute Beschreibung und Lösung zu diesem Thema findet man auf dem Blog von Mike Fourie.