Identifizieren von eingeschlossenen Workitems in TFS 2015 Release Management

Question

Ich versuche den Prozess für vNext Builds und Release Management zu verstehen, um festzustellen, welche Workitems enthalten sind.

Wenn ich bei jedem Check-in einen Build erstellt habe (jedes Mal, wenn eine Arbeit abgeschlossen ist), wird für jedes dieser Builds ein Arbeitselement verknüpft. Ich kann dann eine Release-Bereitstellung dieser Builds in einer QA-Umgebung auslösen, aber dann wird in jedem Release nur dieses eine Element als verknüpft gekennzeichnet - nicht jedes andere, das seit dem letzten Produktions-Release enthalten ist. Da es vor der Bereitstellung in der Produktion mehrere Release-Deploys zur QA geben kann, ist es verwirrend, alle Releases zu filtern.

Ich versuche, eine gute Möglichkeit zu finden, alle Arbeitselemente zu sehen, die in Builds/Releases seit der letzten Produktionsbereitstellung enthalten sind. Missverständnis ich, wie man das benutzt? Sollte ich die gleiche Version verwenden und nur die Zielversion ändern? Es sieht so aus, als ob es "eingefügte Arbeitsgegenstände" von den eingecheckten Arbeitsgegenständen zwischen dem letzten und dem aktuellen Build abbildet.

Answer 1

In der Release-Verwaltung wird die aktuelle Version mit der letzten Version verglichen, um die in der aktuellen Version enthaltenen Workitems anzuzeigen. Sie sehen nur ein Arbeitselement, weil Sie TFS so konfiguriert haben, dass jedes Einchecken erstellt und das Release für jedes Build ausgelöst wird. Wenn Sie nach zwei Builds eine Freigabe auslösen, werden in den beiden Builds zwei Arbeitselemente angezeigt. Die neueste Version von Visual Studio Team Service unterstützt die Auswahl einer Release-Version, die mit der aktuellen Version verglichen werden kann, um die enthaltenen Änderungen und Arbeitselemente aufzulisten. Dies wurde jedoch noch nicht in On-Premise-TFS implementiert.

Sie können jetzt eine weitere Release-Definition erstellen und sie mit demselben Build verknüpfen, um den Build manuell für die Produktion bereitzustellen. Anschließend können Sie die enthaltenen Workitems aus dieser Release-Definition nachverfolgen. Oder Sie können ein App/Powershell-Skript erstellen, um die Build-Version in der Produktionsversion zu lesen und dann die Arbeitselemente über Rest API zu erhalten.