Freitag, 28. August 2015

Gib Deiner Version einen nachvollziehbaren Namen.

Managementaufgaben

Artikelübersicht
1. Teil Managementaufgaben zwischen Fremd- und Selbstverwaltung.
2. Teil Was soll ich zuerst tun? Die Qual der Wahl.
3. Teil Prioritäten verteilen ist eine Kunst.
4. Teil Nur ein Fool wählt gleich ein Tool und ein Plädoyer gegen Monsterprogramme.
5. Teil Wer weiß schon, was alles dazu gehört? Von der Lust oder Unlust zur Versionsverwaltung.
6. Teil Im Dschungel der Nachvollziehbarkeit.
7. Teil Gib Deiner Version einen nachvollziehbaren Namen.
8. Teil Das Erstellen reproduzierbarer Software Releases.


In den letzten Artikeln dieser Reihe haben wir uns mit der Versionierung von Objekten und mit derNachvollziehbarkeit (Traceability) beschäftigt. Heute soll eine Softwarefirma unserer Wahl eine neue Version ihrer brandneuen Software ausliefern. Wir laden sie von der Downloadseite und sehen, sie hat die Versionsnummer 3.9.11. Im Kleingedruckten steht sogar die Nummer 3.9.11.2945. Was hat das zu bedeuten und warum spielt das bei unseren Betrachtungen zur Versionsverwaltung von Artefakten eine Rolle?

Anhand dieser Nummer muss es möglich sein, alle Artefakte eindeutig zu identifizieren, die zu einem Softwarerelease gehören. Das Softwareprodukt muss in dieser Version auf einfache Weise jederzeit neu zu bauen sein. Die Nummer selbst soll uns etwas über das Softwarerelease sagen. Die erste Zahl, in unserem Fall die 3, ist die Hauptversionsnummer (major release). Sie wird nur gewechselt, wenn wirklich eine neue Generation der Software ausgeliefert wird. Einen solchen Wechsel kann man z.B. erleben, wenn die alte Webanwendung, in Perl geschrieben, auf Java und JSF umgestellt wurde. Das Look and Feel hat sich auch geändert und der Funktionsumfang hat einen gewaltigen Sprung nach vorne gemacht. Kurz und gut, erhebliche Änderungen rechtfertigen einen Sprung in der Hauptversionsnummer.



Die zweite Zahl, in unserem Beispiel eine 9, wird gewechselt, wenn die Software mit weiterer Funktionalität ausgestattet wurde. Sie wird auch Nebenversionsnummer (minor release) genannt. Die dritte Zahl, in unserem Fall die 11, kennzeichnet einen Patch zur Fehlerbehebung (patch level). Zur Auslieferung von Patches kann es organisatorische Vereinbarungen geben, wie z.B. Wochen- oder Monatspatches.

Eventuell kann eine vierte Zahl in der Versionsnummer erscheinen. Sie kennzeichnet den Build. Jeder Compilerlauf erzeugt eine neue Buildnummer. Anstatt die Buildnummer zu verwenden, kann auch die Revisionsnummer des Versionsverwaltungssystems benutzt werden. Diese kennzeichnet eindeutig einen spezifischen Stand für ein Kompilat, welches ins Versionsverwaltungssystem eingecheckt wurde. Die Revisionsnummer kann deshalb äquivalent für einen Tag verwendet werden.

Bestimmte Releases einer Software können darüber hinaus extra gekennzeichnet werden. Es kann z.B. unterschieden werden, wer der Adressat der Software ist. Auf der einen Seite wird ein Softwarerelease an die Qualitätssicherung ausgeliefert. Aufgrund von Fehlerbehebungen kann das mehrfach geschehen. Diese Fehlerbehebungen erhöhen das Patch-level jedoch nicht. Die Informationen, die man aus der Hauptversionsnummer, der Nebenversionsnummer und der Nummer zum Fehlerbehebungspatch herauslesen kann, sind ausschließlich für den Kunden bestimmt und sollten sich auch nur in Bezug auf Versionen ändern, die an den Kunden gehen. Im Tagnamen kann man jedoch spezifische Informationen zu Versionen kennzeichnen.

Eine reine Nummer sagt wenig aus. In einen Tagnamen kann man mehr Information unterbringen. Innerhalb einer Firma macht es deshalb Sinn, sich nicht nur eine Konvention für die Versionsnummer zu überlegen, es macht ebenso viel Sinn, die Bestandteile eines Tagnamens festzulegen. Was möchte man im Namen unterbringen? Eine mögliche Information wäre das Erstellungsdatum (z.B. 20150825). Eine andere, ob sich die Version auf den Trunk oder auf einem Branch befindet (z.B. TR, BR). Vielleicht sollte sogar erkennbar sein, auf welchem Branch sie sich befindet. Weiterhin kann der Empfänger erkennbar sein, ist es der Kunde oder die Qualitätssicherung. Es macht also Sinn, sich zusammenzusetzen und eine Konvention auszuarbeiten, an die sich dann alle halten und aus der somit innerhalb kurzer Zeit viele Informationen herauszulesen sind. Diese Festlegungen werden dann im Firmenwiki festgehalten und sind jedermann zugänglich.

Ein solcher Tagname sitzt auf einer Tagline. Eine Tagline ist gleichzusetzen mit einer Baseline. Diese setzen wir über zusammengehörende Artefakte in unterschiedlichen Versionen. Gleichzeitig können wir sie über verschiedene Repositories setzen. Es gibt eine Fülle von Artefakten, die einen Versionsstand repräsentieren. Dazu gehören Anforderungsobjekte, Architekturbeschreibungen, Codedateien, Tests, Handbuchtexte und vieles mehr. Der Tagname kann beim Reproduzieren der Version also sehr hilfreich sein.

Versionsnummern bzw. Tagnamen können jedoch nicht nur für ganze Produkte vergeben werden. Ein Produkt kann aus Komponenten zusammengestellt werden. Dabei muss man wissen, welche Komponente zu welcher Komponente passt. Komponenten sind eigene Teilprodukte mit eigenen Versionsnummern. Zu diesen Teilprodukten brauchen wir Angaben zu ihrer Kompatibilität. Bei diesen Komponenten sollte man die Abwärtskompatibilität beachten. Auf der anderen Seite ist diese nicht hundertprozentig durchhaltbar. Gewisse Ansätze überholen sich mit der Zeit, sollten eine Zeit lang als deprecated gekennzeichnet werden und dann entfallen. In höheren Versionen sind diese Funktionen also nicht mehr verfügbar. Ist die Funktionalität eines älteren Systems bei der Abwärtskompatibilität immer eine Teilmenge der Funktionalität des neuen Systems, durchbrechen entfallene Funktionen dieses Prinzip. Um jedoch „historisch gewachsene Systeme“ zu vermeiden, muss der eine oder andere Architekturfehler auf diese Art behoben werden.

Softwareprodukte können jedoch auch Namen bekommen. Damit meine ich nicht den Namen des Produkts, sondern wirklich den der Version. Die Version 6.0 von Android heißt Marshmallow. Die Version 4.5 von Eclipse heißt Mars. Solche Versionsnamen haben vor allem Marketingcharakter.

vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen