Das Ändern von TFVC Repository Mappings kann Ihren Build unerwartet abbrechen

Vor kurzem bin ich auf einen plötzlich defekten TFS-Build gestoßen. Der Prozess sieht vor, dass wir Hotfixes zunächst über ein Shelveset erstellen, um sie vor der Freigabe ordnungsgemäß testen zu können und mögliche Konflikte mit anderen Bränden zu vermeiden. Der betreffende Entwickler kümmerte sich um den Fehler und erstellte das Shelveset, dann fuhr er mit dem Build fort. Wir haben eine Hotfix-Build-Definition verfügbar, aber die TFVC-Quellzuordnung musste aktualisiert werden, da sie nicht auf den richtigen Zweig zeigte. Dieser Bildschirm unten zeigt die aktuellen Quellzuordnungen, und damit dieser Build funktioniert, musste er die Zweigversion (v2.15 auf v2.16) erhöhen.

Als ich den Build einschließlich des Shelvesets in die Warteschlange stellte, kam alles zum Stillstand. Der Build schlug bereits beim ersten Schritt [Get Sources] fehl, was unerwartet war.

Die Spur

Was hier tatsächlich passiert, lässt sich anhand des Build-Protokolls erklären;

In Zeile 3 wird damit begonnen, alle lokal vorhandenen Änderungen rückgängig zu machen. In diesem Fall werden geänderte assemblyinfo.cs-Dateien eines früheren Builds gefunden. Es spricht nichts dagegen, diese (agentenspezifischen) Änderungen rückgängig zu machen. In Zeile 6 wird angegeben, dass alle Dateien gelöscht werden, die nicht in der lokalen Versionstabelle vorhanden sind. Dazu gehört auch die zuvor erzeugte Build-Ausgabe. Auch das ist in Ordnung.In Zeile 13/14 heißt es dann, dass Sie den Arbeitsbereich abrufen und den gewünschten Änderungssatz zurücknehmen sollen. Und dann macht es "bumm".

Was ist das Problem?

Das Problem ist, dass der Bereinigungsprozess zwar gründlich ist, aber ich habe die Quellverzweigung geändert, und das wird in diesem Prozess nicht berücksichtigt. Nach dem Bereinigungsprozess habe ich also die bereinigten Quellen von Branch v2.15, während ich eigentlich Branch v2.16 brauche.

Wie lässt sich diese Situation umgehen?

Es gibt einige Lösungen. Die ultimative Lösung besteht darin, jedes Mal einen neuen Build-Agenten zu verwenden, damit diese Fehler nicht auftreten. Dies kann mit einem gehosteten Build-Controller geschehen. In meinem derzeitigen On-Premise-Szenario ist dies nicht das idealste Szenario. Eine andere Möglichkeit wäre die automatische Neubereitstellung eines Agenten vor Ort, aber auch das scheint mir etwas weit hergeholt. Eine einfachere Lösung, die immer funktioniert, ist die Verwendung einer leicht veränderten Quellzuordnung von Anfang an, wie in der Abbildung unten zu sehen ist.

Die Auswirkung dieser Änderung ist, dass der Agent v2.15 bereinigt, dann Dateien löscht, dann v2.16 holt, weil dieses Verzeichnis noch nicht existiert, dann das Shelveset freigibt und es mit Erfolg baut. Ein kleiner Nachteil ist, dass der [Get Sources] (Bereinigungsprozess) etwas länger dauert, wenn Sie den Zweig wechseln. Im Protokoll unten können Sie dies überprüfen.