© DrHitch/Shutterstock.com
TFS 2012 Team Build

6 Fallstudie: Erhöhung der Versionsnummern im Build


Ein Thema bei jeder Releasestrategie in Verbindung mit Team Builds ist immer die Erhöhung der Versionsnummern während des Builds. Microsoft liefert auch in der aktuellen Version des TFS keine eingebaute Lösung – was wohl auch damit zusammenhängt, dass die Vergabe von Versionsnummern sehr unterschiedlich ausfallen kann und stark vom Prozess abhängt. Zum Glück kann man mit überschaubarem Aufwand eine eigene Lösung entwickeln, die dann auch exakt auf die eigenen Bedürfnisse zugeschnitten ist.

6.1 Vorschlag für die Vergabe der Versionsnummern

Für die folgenden Ausführungen wird von einem Standard-Branch-Plan ausgegangen, der neben der Haupt- und Entwicklungslinie noch parallele Linien für verschiedene aktive Versionen sowie deren Releases hat. Auf explizite Hotfix-Linien wird verzichtet, stattdessen sind die Releaselinien nicht read-only, sodass Hotfixes in der Releaselinie vorgenommen werden können. Das angenommene Format für Versionsnummern orientiert sich am .NET Framework. Hier hat eine Versionsnummer folgenden Aufbau:

<Hauptversion>.<Nebenversion>.<Buildnummer>.<Revisionsnummer>

Es wird angenommen, dass die Hauptversionsnummer aus strategischen Gesichtspunkten und aus Marketingüberlegungen heraus festgelegt wird. Sie wird stets als Konstante behandelt, die extern vorgegeben wird. Die Nebenversionsnummer soll die parallel aktiven Versionen identifizieren. Die Build- und Revisionsnummern werden durch die Team Builds je nach Codelinie inkremementell erhöht. Die Vergabe der Versionsnummer in Abhängigkeit von der Codelinie ist in Abbildung 6.1 dargestellt.

6_1_VersionIncremente-Branchplan.png

Abbildung 6.1: Vergabe der Versionsnummern

In der Main-Linie werden alle Bestanteile der Versionsnummer auf null festgelegt, mit Ausnahme der Build-Nummer. Diese wird bei jedem nächtlichen Build um eins erhöht. Bei Continuous Integration Builds wird die Versionsnummer der Main-Linie nicht verändert. Die Nullen in der Versionsnummer sollen verdeutlichen, dass dieser Code nie in die Hand des Kunden gelangen soll. Die Main-Linie ist lediglich zur Integration verschiedener Entwicklungen gedacht, nicht dazu, dass deren Code an Kunden ausgeliefert wird.

Bei einer Vorwärtsintegration in die Entwicklungslinie werden die AssemblyInfo.cs-Dateien, in denen die Versionsnummer gespeichert ist, mit übernommen. Auf diese Weise erhält diese Linie immer die gleiche Versionsnummer wie die Main-Linie zum Zeitpunkt der Integration. Die Versionsnummer in der Dev-Linie wird durch die nächtlichen Builds nicht verändert, in den CI-Builds kann aber die Revisionsnummer erhöht werden. Auf diese Weise kann man erkennen, wie lange die letzte Integration in die Main-Linie zurückliegt. Durch die Erhöhung der Revisionsnummer bei CI-Builds erhält man einen Einblick in die Anzahl der laufenden Builds. Bei einer Rückwärtsintegration muss darauf geachtet werden, die AssemblyInfo.cs in der Main-Linie nicht zu überschreiben.

Wann immer eine Versionslinie erzeugt wird, werden Haupt- und Unterversionsnummer aus produktspezifischen Überlegungen festgelegt. Die Nebenversionsnummer kann zum Beispiel fortlaufend für die parallel existierenden Stände einer Hauptversion vergeben werden. Für die Vergabe der Versionsnummer im Build werden diese Versionsnummern als konstant betrachtet und in jedem Build auf den vordefinierten Wert gesetzt. Die Build-Nummer wird aus der Main-Linie übernommen und später nicht mehr verändert. Auf diese Weise ist erkennbar, aus welchem Stand der Main-Linie diese Version hervorgegangen ist. Die Revisionsnummer wird auf null festgelegt und nicht mehr verändert. Die Versionsummer dieser Linien ist somit konstant. Da auch dieser Code nicht an Kunden ausgeliefert wird, ist eine Erhöhung der Versionsnummer pro Build hier nicht erforderlich.

Zusammen mit dem Versionsstand wird auch der Releasezweig erzeugt, der initial die gleiche Versionsnummer wie sein Ursprungszweig erhält. Bei jedem Build wird die Revisionsnummer um eins erhöht. Damit wird der Patch-Level dieses Release ausgedrückt, da ein Build auf einer Releaselinie nur durch die Korrektur eines Fehlers ausgelöst werden kann. Pro Hotfix wird diese letzte Stelle also um eins erhöht.

In Tabelle 6.1 ist noch einmal schematisch dargestellt, wie sich die Versionsnummern in den einzelnen Codelinien zusammensetzen und durch welche Builds sie in welcher Art und Weise verändert werden.

Linie

Trigger

Major

Minor

Build

Revision

DEV

Vorwärts-integration

0

0

Wie MAIN

o

CI-Build

0

0

Wie Main

+1

MAIN

Initial

0

0

0

0

Nightly-Build

0

0

+1

0

VERSION

Initial

Vorgabe

Vorgabe

Wie MAIN

0

RELEASE

Initial

Wie VERSION

Wie VERSION

Wie Version

0

Manual Build

Wie VERSION

Wie VERSION

Wie VERSION

+1

Tabelle 6.1: Struktur der Versionsnummern

6.2 Entwicklung der notwendigen Workflow Activities

Um die gestellten Anforderungen zu erfüllen, müssen folgende Schritte unternommen werden:

  • Auschecken der AssemblyInfos (je nach Projekttypt mit Endung .cs oder .vb)
  • Erhöhung der Versionsnummer – dabei muss das entsprechende Muster einstellbar sein
  • Einchecken der Dateien

Für diese Tätigkeiten müssen jeweils eigene Aktivitäten implementiert werden.

CheckOut-Aktivität

Die benötigten Parameter der CheckOut-Aktivität sind Listing 6.1 zu finden.

[RequiredArgument]
public InArgument<string> AssemblyInfoFileMask { get; set; }

[RequiredArgument]
public InArgument<Workspace> Workspace { get; set; }

Listing 6.1: Parameter der „CheckOut“-Aktivität

Die Aktivität zum Auschecken der AssemblyInfo-Dateien benötigt als Eingabeparam...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang