Microsoft hat bereits mit TFS 2013 eine weitere Komponente in die Visual Studio ALM Familie integriert: Release Management. Im Wesentlichen arbeitet dieses System mit der Windows Workflow Foundation zur Ablaufsteuerung. Wir empfehlen unseren Kunden seit längerem bei der Erweiterung nicht auf workflowbasierte Activities zu setzen, da sich hier einiges verändern wird. Beim Lesen der Release Notes des TFS 2015 fällt außerdem auf, dass die Änderungen an Release Management weniger groß ausfallen. Wir erklären, warum das so ist, wie Sie sich gut für die Zukunft rüsten können und was Microsoft in Zukunft bereitstellen wird.
Was ist der Unterschied zwischen Team Builds und Release Management? Wann wird welche Komponente genutzt? Die Abgrenzung zwischen den Buildsystemen des TFS 2015 und Release Management ist recht einfach. Beim Team Build wird aus Quellcodedateien ausführbarer Code (zum Beispiel DLL oder EXE) generiert. Release Management verteilt nacheinander dieses Buildergebnis auf verschiedene Umgebungen. Ist das Buildergebnis auf dem Zielsystem installiert, wird das Release freigeben (siehe Approver in Abbildung 1) und das Deployment erfolgt automatisch auf das nächste Zielsystem in der Release Pipeline (gelbe Pfeile in Abbildung 1). Ein Stoppen des Buildprozesses für manuelle Interaktion, wie das Freigeben eines Release, ist beim Team Build nicht vorgesehen. Eine typische Release Pipeline beginnt mit einem Entwicklungssystem, einem QA-System und dem endgültigen Produktivsystem.
Abbildung 1: Konfiguration eines Release Paths bestehend aus Dev, QA und Prod mittels Release Management Client
Die Schritte während des Deployments werden in einem Workflow definiert. Im Vergleich zu XAML Builds stehen die konfigurierten Workflows nicht als XAML-Dateien zur Verfügung, sondern werden von Release Management selbst verwaltet. Damit ist es leider nicht möglich selbsterstellte Workflows im Source Control abzulegen und zu versionieren. Release Management bietet zwei verschiedene Release Templates: Mitgelieferte Actions und Tools können im Agend-based Release Template genutzt werden (siehe Abbildung 2). Das vNext Release Template hingegen bietet die Möglichkeit PowerShell und PowerShell DSC-Skripte auszuführen sowie das Configuration Management Tool Chef zu integrieren (siehe Abbildung 3).
Abbildung 2: Agent-Based Release Template
Abbildung 3: vNext Release Template
Ein Release kann jederzeit manuell im Release Management Client gestartet werden. Für den automatischen Start eines Releases nach einem erfolgreichen Build muss in TFS 2015 das verwendete Buildsystem berücksichtigt werden.
XAML Builds
Der Release Management Client enthält ein erweitertes Build Process Template. Dieses ist im Installationsverzeichnis (standardmäßig C:\Program Files (x86)\Microsoft Visual Studio 14.0\Release Management\Client\bin) zu finden und muss in das Source Control eingecheckt werden. Danach kann das Template ausgewählt und konfiguriert werden. Wie Abbildung 4 zeigt, enthält das Build Process Template einen zusätzlichen Abschnitt für die notwendigen Parameter, wie zum Beispiel die Zielumgebung (Release Target Stage).
Abbildung 4: Automatisches Release im bisherigen Buildsystem konfigurieren
TFS 2015 Builds
Im neuen Buildsystem des TFS 2015 muss der Build Task Publish Build Artifacts hinzugefügt und in Release Management 2015 müssen vNext Release Templates verwendet werden. Der Artifact name in der Builddefinition (siehe Abbildung 5) und der Component Name in Release Management (Abbildung 6) müssen übereinstimmen.
Abbildung 5: Konfiguration im TFS 2015 Buildsystem
Abbildung 6: Konfiguration in Release Management 2015
Somit kann Release Management in beiden Buildsystemen verwendet werden.
Neben der Kompatibilität zum neuen Buildsystem sind nur kleinere Verbesserungen in Release Management eingeflossen, wie zum Beispiel Fehlerkorrekturen und Optimierungen des Clients und die Synchronisierung von Active Directory- und TFS-Sicherheitsgruppen.
Ausblick
Dass die Änderungen an Release Management 2015 marginal sind hat einen guten Grund: Ende April gab Microsoft bekannt, dass zukünftig für das Release Management die gleiche technische Basis des neuen Buildsystems genutzt werden soll (Quelle: http://blogs.msdn.com/b/bharry/archive/2015/04/29/visual-studio-and-team-foundation-server-at-build-2015.aspx). Damit profitieren alle Anwender von den Neuerungen, wie zum Beispiel die Konfiguration via Webbrowser und Plattform-unabhängiger Ausführung. Wie an anderer Stelle nachzulesen ist, wird es am bisherigen Release Management keine signifikante Weiterentwicklung geben (Quelle: http://blogs.msdn.com/b/visualstudioalm/archive/2015/04/29/release-management-announcements-at-build-2015.aspx).
Wie bereitet man sich nun auf die Umstellung am besten vor? Nutzer von Agent-Based Release Templates sollten sämtliche Erweiterungen in PowerShell implementieren und die bereits vorhanden vNext Release Templates dafür verwenden. Wie auch beim Buildsystem wird die Umstellung nicht abrupt erfolgen, so dass die kommende Umstellung bei Neuimplementierungen unbedingt berücksichtigt werden sollte.
Für Nutzer von TFS 2015, die bald mit Release Management beginnen wollen, stellt sich die Frage, ob das aktuelle Release Management verwendet werden soll oder auf die nächste Version gewartet werden soll. In diese Entscheidung fließt auch die geplante Veröffentlichung von Release Management vNext ein. Bisher ist noch kein Termin offiziell bekannt gegeben worden. Auch die VSO Feature Timeline (Quelle: https://www.visualstudio.com/en-us/news/release-archive-vso.aspx), in der auch neue Features für TFS On-Premise angekündigt werden, zeigt nur die geplante Public Preview für das vierte Quartal (siehe Abbildung 8).
Abbildung 8: Aktuelle Visual Studio Online Features Timeline
Fazit
Release Management 2015 bietet im Wesentlichen Fehlerkorrekturen und kleinere Optimierungen. Für die Kombination mit Team Builds, muss je nach eingesetztem Buildsystem das entsprechende Release Template verwendet werden. Das Deployment von Buildergebnissen, welche mit dem neuem Buildsystem generiert wurden, ist nur mit vNext Release Templates möglich. Die Nutzung von XAML-Builds in Kombination mit Agent-Based Release Templates ist nach wie vor möglich, muss jedoch in Erwartung einer neuen technischen Basis von Release Management perspektivisch umgestellt werden.
Hinweis zum Update von Release Management 2015
Dass bei der Installation von Updates vorherige Versionen von Release Management (Server, Client und Deployment Agent) manuell deinstalliert werden müssen, ist weiterhin notwendig. Bei der Deinstallation des Servers bleibt die Datenbank erhalten. Nach der Installation müssen lediglich die Zugangsdaten erneut eingetragen werden.