Wie stellt man sicher, dass die richtigen DLLs ausgeliefert werden? Wie kann man die Integration der eigenen Software vereinfachen? Wie werden Assemblies richtig versioniert? Wie behalt man den Überblick über die Bestandteile der eigenen Software? Die Antworten darauf liegen in der richtigen Versionierungsstrategie…
Oft stellt sich die Frage, welcher Stand eines Produktes an Kunden ausgeliefert wurde. Um diese Frage beantworten zu können, müssen die unterschiedlichen Stände leicht und zuverlässig identifizierbar sein. Hier hilft nicht nur eine eindeutige Versionsnummer in DLLs und Anwendungen.
Dieser Artikel geht zuerst auf den Aufbau von Versionsnummern ein, beschreibt das empfohlene Vorgehen bei der Vergabe von Versionsnummern und zeigt am Ende wie diese automatisch mit Team Foundation Build und der AIT Build Suite erzeugt und .NET Assembly-Attribute effizient bei der Entwicklung der Produkte abgelegt werden können.
Aufbau der Versionsnummern
Die klassische Versionsnummer untergliedert sich in vier Stellen: <Major>.<Minor>.<Build>.<Rev>: Die Haupt- bzw. Nebenversionsnummer des Produktes (Major und Minor Version) werden in der Major und Minor Stelle gespeichert und klassischerweise vom Produkt Management oder der Marketing-Abteilung vorgegeben. Die Buildnummer wird in der Stelle Build gespeichert. In der vierten Stelle (Rev) wird die Revisionsnummer gespeichert. Der Gültigkeitsbereich der ersten drei Stellen ist auf maximal 65535 beschränkt. Die vierte Stelle kann maximal auf einen Wert von 9999 wachsen.
Empfohlene Versionierung
Wichtig bei der Versionierung ist die Generierung einer streng monoton wachsenden und dadurch eindeutigen Versionsnummer. Weiterhin ist zu beachten, dass Installer nur die Major, Minor und Build Stelle einer Datei überprüfen, um zu bestimmen, ob eine Datei bei einem Update ersetzt werden muss.
Die Major und Minor Stelle der Versionsnummer des Produkts und sollte von außen vorgegeben werden (Zum Beispiel über Parameter in der Build Definition).
Die Build Stelle der Versionsnummer sollte auf das Datum des aktuellen Builds gesetzt werden. Zusammen mit dem in der Revisionsstelle gespeicherten Build des Tages ergibt sich eine monoton wachsende Versionsnummer. Durch die Begrenzung auf einen maximalen Wert von 65535 kann hier jedoch nicht das komplette Datum gespeichert werden, sondern es muss das Jahr bezogen auf ein Basisjahr gespeichert werden. Bei einer Erhöhung der Hauptversionsnummer sollte das Basisjahr auf das aktuelle Jahr gesetzt werden, um nicht den Wertebereich von 65535 zu überschreiten. Mit diesem Vorgehen ist eine valide Versionsnummer für einen Zeitraum von maximal sechs Jahren gewährleistet.
In der Rev Stelle der Versionsnummer sollte der aktuelle Build des Tages gespeichert werden, da sich hiermit eine Version von erzeugten Assemblies über die Versionsnummer eindeutig einem Build zuordnen lässt. Zu beachten ist, dass die letzte Stelle von Installer-Tools bei einem Update (meist) nicht beachtet wird.
Für ein Produkt wie den AIT Dependency Manager (Produktversion Version 1.0, Erstveröffentlichung im Jahr 2011), welcher am 21. Februar 2012 erstellt würde (10 Build des Tages), ergäbe sich die folgende Versionsnummer: 1.0.10221.10
Diese setzt sich aus der vorgegebenen Major und Minor Stelle "1.0", dem Basisjahr aus 2012 – 2011 = "1", Monat Februar "02", Tag des Monats "21" für Build und dem Build "10" des Tages für diese Build-Definition im TFS für Rev.
Um die Versionsnummer in den Assemblies abzulegen empfiehlt sich das Assembly Attribut AssemblyFileVersion. Das Attribut AssemblyVersion sollte hingegen auf eine (feste) Versionsnummer von Major.Minor.0.0 gesetzt werden (Im Beispiel 1.0.0.0), um Problemen bei der Verwendung von Strong Name Assemblies vorzubeugen – ansonsten müssen Sie für jeden Build alle Assembly-Referenzen aktualisieren. Zusätzlich empfiehlt es sich, die Team Foundation Build Number des Builds (z.B. "DependencyManager_Main_1.0.10221.10") im Attribut AssemblyDescription abzulegen, um aus den erstellten Assemblies auch die Build Definition und damit verbunden den Branch erkennen zu können. Zudem entspricht die Build Number auch dem Label welches durch den Build-Prozess im Source Control gesetzt wurde und damit die Nachvollziehbarkeit von Assembly über Build zur Versionskontrolle komplett macht.
Automatisches Setzen der Versionsnummer
Voraussetzung für das automatische Generieren und Setzen der Versionsnummern (als AssemblyFileVersion) ist die AIT Build Suite. Folgende Schritte sind mit der AIT Build Suite dafür im Tab Process der Build-Definition nötig:
- Ändern des Build Process Templates auf AITDefaultTemplate.V21.xaml
- Anpassen der Einstellungen Release Management
- Setzen eines Wertes für BaseYear (Im Beispiel auf 2011)
- Entweder Setzen der ExplicitVersionInfo (1.0 im Falle des Beispiels) oder Nutzung der Major und Minor Version in der AssemblyInfo.cs des Projekts
- UpdateVersionInfo auf BaseYear einstellen
Konsolidierung von Assembly-Informationen
Für ein Produkt sollten Informationen die für alle erzeugten Assemblies gleich sind wie z.B. Firma, Produktname, Copyright, Trademark und Attribute für die Versionierung in einer gemeinsamen GlobalAssemblyInfo.cs Datei abgelegt sein. Assembly-spezifische Informationen wie der Assembly-Titel oder die GUID müssen in den projektspezifischen AssemblyInfo.cs Dateien verbleiben.
Dies erleichtert die Verwaltung, da diese Informationen nur einmal gepflegt werden müssen. Um dies zu erreichen sollten Sie wie folgt vorgehen:
- Zuerst wird eine projektübergreifende GlobalAssemblyInfo.cs Datei in der Solution (z.B. Solution Items) des Produktes angelegt
- Beschreibende Attribute (AssemblyTitle, AssemblyCompany, AssemblyCopyright und AssemblyTrademark)
- Attribute zur Versionierung (AssemblyDescription, AssemblyFileVersion und AssemblyVersion)
- In jedem Projekt wird ein Link auf die GlobalAssemblyInfo.cs Datei eingefügt
- In der GlobalAssemblyInfo.cs hinterlegte Attribute werden aus den projektspezifischen AssemblyInfo.cs Dateien gelöscht
Fazit
Mit der richtigen Versionierung gelingt es, ein Produkt auf den Build und die Version der Quellcode-Dateien zurückzuführen, wie im Falle von AIT WordToTFS:
Hier lassen sich die Produktversion (1) und die Build Number (2) ablesen.
Viel Erfolg bei der richtigen Versionierungsstrategie!