Auf der MSDN ist ein neuer Webcast von uns verfügbar – zum Thema Releasemanagement mit dem VSTS. Die Details werden zum Nachlesen hier noch einmal näher beschrieben.
Work Items im Team Build
Ein typischer Buildbericht im TFS enthält neben den Metadaten zum Buildprozess (z.B. Datum der Ausführung, Revisionsnummer des gebauten Sourcecodes usw.) auch die Änderungen (Changesets) und assoziierten Work Items, die zu diesem Build beigetragen haben.
Doch wie wählt der Team Build die zu assoziierenden Änderungen und Work Items aus?
Diese Auswahl basiert auf den Labels, die jeder Build in der Versionsverwaltung anlegt. Diese tragen den Namen des Builds, die sogenannte Buildnummer (z.B. Test Build 20081006.3). Ein intern berechneter Parameter für den Build ist das LastGoodBuildLabel – das Label des letzten erfolgreichen Builds. Erfolgreich bedeutet hier erfolgreiche Kompilierung und Unit-Tests.
Es werden also alle Änderungen assoziiert, die seit diesem letzten erfolgreichen Build hinzugekommen sind. Zu diesen Änderungen gehören auch Work Items, die beim Einchecken mit diesen Änderungen verknüpft wurden. Die Verknüpfung kann durch eine Checkin-Richtlinie sichergestellt werden.
Buildqualität
Ob ein Build als erfolgreich oder als nicht erfolgreich bewertet wird, hängt also zunächst nur von Kompilierung und Unit-Tests ab. Visual Studio Team System bietet aber für das Build- und Release-Management noch mehr. Im Build Explorer, der die gelaufenen Builds anzeigt, kann man z.B. die Buildqualität einstellen – eine weitere Eigenschaft eines Builds, die dazu dient, ein manuell eingestelltes Qualitätsattribut einzufügen.
In der Abbildung ist die Liste der verfügbaren Buildqualitäten erkennbar. Diese Liste lässt sich verändern und an die eigenen Bedürfnisse anpassen. So kann man einem Build z.B. die Qualität "Testbar" oder "Ausgeliefert" zuordnen.
Um nun die Auswahl des letzten erfolgreichen Builds nicht am Kompilierungsstatus sonder an der Buildqualität festzumachen, muss man etwas Anpassungsaufwand betreiben. So haben wir bei einigen Kunden diesen Mechanismus auf die Buildqualität "umgebogen". D.h., dass alle Änderungen und Work Items mit dem Build assoziiert werden, die seit dem letzten "Ausgeliefert"-Build hinzugekommen sind. Das entspricht dann schon eher den gewünschten Release-Notes.
Release Notes
Doch wie kommt man dann eigentlich zu einer Liste der in eine Version eingeflossenen Änderungen, Bug-fixes, Features usw.?
Der Build trägt in alle assoziierten Work Items einen Wert in das Feld "Integration Build" ein – die Buildnummer. Diese kann dann in Work Item Queries über den Operator "Was Ever" abgefragt werden. Dadurch erhält man eine Liste aller Work Items, die Teil eines oder mehrerer bestimmter Builds waren.
Diese Liste lässt sich dann in Visual Studio oder in Excel ausdrucken, exportieren usw.. Wir haben diese Liste auch schon im Buildprozess als XML exportiert, um dann spezifischere Transformationen (z.B. in HTML) durchzuführen, die wiederum als Eingabe für weitere Tools dienen können.
Fazit
Das Visual Studio Team System unterstützt beim Release-Management. Dennoch gehört dazu auch ein abgerundeter Prozess. Wenn erst gar keine Work Items verwendet werden, lassen sich diese auch nicht zu Release-Notes zusammenfassen. Abweichungen vom Standardverhalten sind in den meisten Fällen mit wenig Aufwand umsetzbar. So kann das Release-Management an die eigene Vorgehensweise und Tool-Landschaft angepasst und insgesamt abgerundet werden.