Freitag, 11. September 2015

Das Erstellen reproduzierbarer Software Releases.

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.


Im letzten Post haben wir uns darum gekümmert, unserer Software einen Namen zu geben. Für den Kunden wurde ein eingängiger Marketingname erfunden, für die Entwicklung reichte eine interpretierbare Versionsnummer. Diese Versionsnummer beinhaltet Information. Wiederfinden kann man den Versionsnamen im Tagnamen, der auf der Tagline (Baseline) in der Versionsverwaltung sitzt. Dieser Tagname kann weitere, vielfältige Informationen zur Version enthalten.

Mit dem Setzen der Tagline haben wir einen der notwendigen Schritte zur Veröffentlichung eines Softwarereleases bereits ausgeführt. Bevor wir diese Tagline setzen, sollten wir jedoch die Versionsnummer auf die auszuliefernde Releaseversion setzen. In Maven gibt es beispielsweise das Versionstag. Solange die Software in der Entwicklung ist, tragen wir dort die zukünftige Version als Snapshot ein.

<version>2.0.15-SNAPSHOT</version>

In diesem Zusammenhang reicht es nicht, sich um diese eine Releaseversion zu kümmern. Ein Softwareprojekt kann vielfältige Abhängigkeiten enthalten. Deshalb muss in allen Abhängigkeiten geprüft werden, ob es sich auch dort um Releaseversionen und nicht um Snapshotversionen handelt. Erst wenn alle Abhängigkeiten erfolgreich die Prüfung bestanden haben, können wir unser auszulieferndes Softwarerelease von einer Snapshotversion auf eine Releaseversion ändern.

Nun folgt erst, was wir im letzten Post besprochen haben, alle Dateien werden in diesem Stand in die Versionsverwaltung eingecheckt und danach getaggt. Zu den eingecheckten Dateien in der Versionsverwaltung gehören neben dem Sourcecode natürlich auch Hilfetexte, Konfigurationsdateien, Tests und so einiges mehr. Alle diese Quellen können Sie jederzeit in dieser getaggten Version reproduzieren.

In Maven werden alle Abhängigkeiten im Dependencybereich verwaltet. Dort steht, welche Libraries in welcher Version zum Bauen unserer Software notwendig sind. Für diese Abhängigkeiten können verschiedene Gültigkeitsbereiche angegeben werden. Manche Bibliotheken werden nur während der Tests benötigt, andere nur in der Compile- und in der Testphase, weil sie im Container, in dem unsere Software laufen soll, bereits enthalten sind.



Die Bibliotheken werden aus einem Repository bezogen. Für die Bibliotheken sollten wir ein eigenes Repository aufbauen. Eigene Bibliotheken entwickeln wir als eigenständige Softwareprojekte und liefern sie als Softwarereleases an dieses Repository aus. In anderen Softwareprojekten tragen wir nur die Abhängigkeit für den benötigten Versionsstand dieser Bibliothek ein. Im Softwareprojekt wird dann auch nur diese Abhängigkeit eingecheckt.

Nachdem wir das Projekt eingecheckt und getaggt haben, können wir es ausliefern. Das erfolgt in unserem oben erwähnten Repository. Dort können wir es entnehmen und es unseren Kunden bereitstellen. Danach müssen wir nur dafür sorgen, dass wir in der Entwicklung weiterarbeiten können. Es muss eine neue Snapshotversion erzeugt werden. Diese stellt unser neues, anzustrebendes Ziel dar. Auch das muss wieder in der Versionsverwaltung eingecheckt werden.

Alle Schritte zusammen ergeben ein ordentliches Stück Handarbeit. Wer alle diese Schritte selbstständig ausführen muss, weiß wie viel man dabei falsch machen kann. Jeder Fehler kostet Zeit und Nerven. Deshalb ist ein System wie Maven zum Konfigurationsmanagement nur zu empfehlen. Vieles, was früher Schritt für Schritt mit dem eigenen Kopf durchgeführt werden musste, wird nun automatisch von Maven erledigt.

Mit dem prepare-Goal werden die Abhängigkeiten geprüft, die Versionen gesetzt und die Tags erzeugt. Mit dem perform-Goal wird die Softwareversion in das Repository deployed. Daneben gibt es einige weitere Goals, die in Maven beim Veröffentlichen von Software eine Rolle spielen. Ich möchte hier jedoch nicht Maven erläutern, sondern nur aufzeigen, dass sich viele Schritte durch diverse Tools automatisieren lassen.

Eine Automatisierung beim Ausliefern von Software, ist in jedem Fall zu empfehlen. Die Vielzahl der Dateien und der durchzuführenden Schritte birgt die Gefahr, den Wald vor lauter Bäumen nicht mehr zu erkennen. Die Automatisierung minimiert Fehler und beschleunigt den Vorgang. Natürlich sind ein paar Schritte notwendig, um solche Automatismen aufzubauen. Das Team muss sich mit einem Konfigurationsmanagementsystem beschäftigen, es verstehen lernen und dann muss das System geplant und aufgebaut werden. In einem Testprojekt kann man erste Erfahrungen sammeln.

Die Energie, die ein Team in die Automatisierung steckt, wird sich später vielfach bezahlt machen. Sicher reproduzierbare Software Releases sind nicht nur wünschenswert, sie sind notwendig. Leider gibt es immer noch Auslieferungen, die durch ein heilloses Durcheinander gekennzeichnet sind. Man sucht an allen möglichen Orten nach auszuliefernden Artefakten und stellt diese per Hand zusammen. Dann schwitzt man und versucht die Software zum Laufen zu bewegen, doch es fehlt noch das eine oder andere. Falls man zu diesen Getriebenen gehört, sollte man sich in Ruhe zurücklehnen und im Team überlegen, wie man den Weg der Automatisierung beschreiten will. Wenige Wochen später wird sich niemand mehr an die unglücklichen Zeiten erinnern.

vorheriger Post dieses Themas


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

1 Kommentar:

  1. Im Linux-OS Debian ist Reproduzierbarkeit ebenfalls ein Thema: https://wiki.debian.org/ReproducibleBuilds

    AntwortenLöschen