Release Management mit dem Team Foundation Server von Microsoft

Das Release Management ist im Allgemeinen bekannt als ein Vorgang von Verwaltung, Terminierung und Steuerung einer Software, die durch verschiedene Stufen in unterschiedlichen Umgebungen wandert. Dazu zählen außerdem auch das Testen, das Automatisieren von Tests und das Deployen von Software Releases. Diese und auch weitere Konfigurationsmöglichkeiten beinhaltet das Release Management, welches für Visual Studio Team Services als auch für den Team Foundation Server (Update 2 oder höher) angeboten wird.Microsoft bietet nahtlose Integrations- und Automatisierungsmöglichkeiten in Entwicklungsumgebungen für agile Teams. Das Release Management kann zum einen von Softwareentwicklern für eine kontinuierliche, automatisierte Bereitstellung genutzt werden. Zum anderen wenden es große Unternehmen an, um die Effizienz und Zusammenarbeit zwischen verschiedenen Teams zu verbessern, die im Release-Prozess involviert sind.
Um das Release Management zu verwenden, werden Release-Definitionen angelegt, in denen Tasks erstellt und in jeder Umgebung ausgeführt werden sollen. Es können mehrere Umgebungen in jeder Definition gruppiert werden, um den Softwarelebenszyklus zu modellieren. Die Bereitstellung in jeder Umgebung kann nach verschiedenen Optionen und Kriterien automatisch ausgelöst werden.

Abb.1 [1]

Wann sollte man das Release Management mit dem Team Foundation Server in Betrachtung ziehen?

• Es wird eine Anwendung entwickelt, die regelmäßig auf eine Plattform deployed werden muss: Es werden bereits viele Tasks out-of-the-box bereitgestellt, um eine Vielzahl von Anwendungen zu implementieren. Sollte es einen Task nicht out-of-the-box geben, gibt es immer noch die Möglichkeit ein Shell- oder PowerShell-Skript auszuführen, um mit dem Release Management zu arbeiten. Es werden auch Drittanbieter-Systeme wie Chef oder Docker unterstützt.
• Bei der Verwendung von Continuous Integration (CI) Systemen: Egal ob Team Services, Team Foundation Server oder Jenkins als CI-System verwendet wird, kann das Release Management entsprechend eingerichtet werden, um automatisch neue Builds in mehrere Umgebungen zu deployen.
• Der Fortschritt des Releases muss verfolgbar sein: Wenn mehrere Umgebungen (siehe Abb.1) verwendet werden, unterstützt das Release Management einen bei der Überwachung, ob ein Release in jede dieser Umgebungen deployed und getestet wurde. Außerdem wird verfolgt, ob ein Entwickler einen Fehler behoben hat oder ob ein Backlog Item erledigt und deployed wurde.
• Es wird eine Kontrolle über alle Deployments benötigt: Mit dem Release Management kann festgelegt werden, welcher Benutzer die Konfiguration einer Umgebung ändern oder ein Release genehmigen kann. Wenn es ein Problem mit dem Deployment gibt, hilft das Release Management einem dabei, zu einem vorherigen Deployment zurückzuspringen und alle Logfiles an einem Ort bereitzustellen, um dem Problem auf den Grund zu gehen.
• Es wird ein Verlauf für alle Releases und deren Deployments benötigt: Das Release Management bietet einen Überblick über alle Änderungen an Definitionen, Konfigurationen und Deployments. Es gibt auch einen Verlauf der alle Aktivitäten beinhaltet, die während jedem Deployen durchgeführt wurden. Jedes Release wird begleitet von einer Auflistung an neuen Features und Entwickler Commits, die es in diese Version geschafft haben.

Release Management Workflow

 
Beim Verwenden des Release Management mit dem Team Foundation Server sind nachfolgend die Schritte, nach denen typischerweise vorgegangen wird:
1. Erstellen einer Release Definition: Die Einrichtung startet mit der Erstellung einer Release Definition im „Build- und Release“- Tab im jeweiligen Teamprojekt.
2. Hinzufügen von Umgebungen: Der bereits erstellten Definition werden nun eine oder mehrere Umgebungen hinzugefügt. Jede Umgebung repräsentiert ein Deployment Target für das Release. So können beispielsweise Umgebungen für Tests, Qualitätssicherung, Staging und Produktion erstellt werden(siehe Abb.1). Anschließend werden den Umgebungen die Benutzer zugewiesen, die die Bereitstellungen genehmigen müssen – sofern dies gewollt ist. Es ist auch einstellbar, dass eine Umgebung erst starten kann, sobald die vorherige Umgebung das Deployment genehmigt hat. Andersrum ist es genauso möglich einer oder mehreren Umgebungen parallel den Job zu übergeben, so dass niemand im Projekt aufgehalten wird.
3. Hinzufügen von Tasks: Jeder Umgebung können nun Tasks hinzugefügt werden, die automatisch durchgeführt werden sollen. Es gibt bereits eine Vielzahl von vordefinierten Tasks, die verwendet werden können (Abb.2).

Abb.2

4. Erstellen und Bereitstellen von Releases: Sobald eine Release Definition erstellt wurde, kann auf dieser Basis eine neue Version erstellt und in verschiedene Umgebungen implementiert werden. Es gibt eine breite Palette von Optionen für die Erstellung eines Release und deren Bereitstellung. Unter anderem ist es auch möglich, ein Veröffentlichungszeitpunkt zu setzen. Es können auch alle Änderungen, die in ein Release eingegangen sind, überwacht werden.
5. Verfolgen von Deployments: Wenn ein Release für verschiedene Umgebungen bereitgestellt wird, kann der jeweilige Fortschritt einzeln nachverfolgt werden. Es können neue Deployments in einer Umgebung genehmigt werden und die Protokolle der Deployments angezeigt werden.

Das Release Management eignet sich gut beim Verwalten, Terminieren und Steuern einer Software, die beim Release Vorgang durch verschiedene Abschnitte gereicht wird, um ein ordnungsgemäßes Release zu gewährleisten. Dazu zählen unter anderem das Deployen von Software Releases und das Automatisieren von Tasks. Out-of-the-box werden auch schon viele Tasks bereitgestellt und ggf. lassen sich auch eigene Skripte oder Programme über ein Shell Kommando ausführen. Da das Release Management noch relativ neu ist, ist der Support noch etwas begrenzt [2].
In zukünftigen Projekten wird das Release Management auch bei doubleSlash zum Einsatz kommen.

Quellen: