Stell dir vor, du besuchst die Fertigungshalle eines großen Automobilherstellers. Du betrittst die Halle und siehst kein Fließband, keine Fertigungsroboter, keine Qualitätssicherung – stattdessen werkelt jeder einfach vor sich hin.
Nach ein paar Jahren Produktionszeit werden die Einzelteile zu einem Auto verbunden und dem Werksleiter zur Abnahme übergeben. Dieser fährt nun testweise ein paar Meter, bis das Auto den Geist aufgibt und in sich zusammenfällt.
Zum Glück arbeitet die Automobilindustrie nicht auf diese Weise – und auch in der Software-Entwicklung sollte es so nicht aussehen.
Denn “Fließband”, “Fertigungsroboter” und “Qualitätssicherung” sind bereits in der Welt der Software-Entwicklung angekommen: Sie nennen sich Deployment Pipeline, Build-Automatisierung und automatisierte Tests.
Die Deployment Pipeline stellt sicher, dass Änderungen, die wir als Entwickler an unserer Software vornehmen, auch tatsächlich wie gewünscht beim Anwender ankommen – und das so schnell wie möglich. Die Code-Qualität und Funktionalität wird auf dem Weg dahin geprüft, im besten Fall vollautomatisiert. Wichtig dabei ist, dass jede Änderung direkt ins gesamte System eingespeist wird. Das Ganze erreichen wir wie folgt:
Alles wird in einem Versionsverwaltungssystem wie Git verwaltet – vom Build-Skript bis zu den Testdateien. Warum? So sind alle Änderungen, auch solche an der Infrastruktur oder am Build-Prozess, rückverfolgbar und alles kann von überall per Knopfdruck bearbeitet werden. Eine vereinfachte Branching-Strategie kann dabei zum Beispiel so aussehen:
Entwickelt wird auf Develop. Sobald ein Release ansteht, wird eine Versionsnummer vergeben und auf Testing gemerged. Dieser Branch dient ausschließlich zum Testen. Das heißt, nachdem die Software die automatisierten Tests bestanden hat, wird sie an Test-User ausgeliefert. Probleme und Bugs mit dieser Version werden dann ausschließlich auf diesem Branch behoben und anschließend zurück zu Develop gemerged. Auf Develop kann parallel bereits an neuen Features für das nächste Release gearbeitet werden. Wenn die Testphase erfolgreich war, wird von Testing auf Release gemerged und die Software an den Endbenutzer ausgeliefert.
Mittels Werkzeugen wie Gradle und Maven kann die Software sowohl lokal, als auch automatisiert auf einem Build-Server gebaut werden. Nach jeder Änderung am Code sollte ein Build-Prozess ausgelöst werden, der sicherstellt, dass die Änderungen erfolgreich kompilieren. Im Grunde ist das die erste Bewährungsprobe für unsere Änderung, bevor es ins Testing geht.
Komponenten- und Integrationstests gewährleisten, dass der Code das macht, was er soll und bestehende Funktionalitäten nicht verändert werden. Deswegen muss jede neue Funktionalität durch Tests abgedeckt sein, sonst können zukünftige Änderungen diese ungewollt manipulieren. Die automatisierten Tests sollten in einem Umfeld laufen, dass dem produktiven Umfeld am nächsten kommt. Manuelles Testen sollte auf ein Minimum reduziert werden. Und mal ehrlich: Wer hat dazu auch Lust? Frameworks wie Espresso (Android) und SWTBot (Java) nehmen einem das manuelle Klicken gerne ab.
Nachdem der Code die Tests erfolgreich bestanden hat, wird er an den User ausgeliefert – natürlich wieder möglichst automatisiert. Handelt es sich bei unserer Software zum Beispiel um eine Android App, wird diese im Play Store veröffentlicht und die User bekommen eine Update-Benachrichtigung. Im Eclipse-Umfeld bekommen die User das Update über die entsprechende Update-Site. Mittlerweile gibt es genug Werkzeuge, die uns beim Automatisieren der Auslieferung unterstützen. Jenkins und Co bieten diverse Plug-ins dafür an.
Auf der Branching-Strategie aufbauend, kann eine vereinfachte Deployment Pipeline wie folgt aussehen:
Das Ausliefern an Test User ist hier als optional eingezeichnet. Der Idealfall wäre natürlich, dass sämtliche Funktionalitäten durch automatisierte Tests abgedeckt sind und somit manuelle Tests wegfallen.
Das Wichtigste in der Zeichnung ist jedoch die Feedbackschleife. Das Feedback sorgt dafür, dass wir immer wissen, ob wir uns in die richtige Richtung bewegen oder nicht. Je schneller das Feedback kommt desto besser.
In unserem Eingangsbeispiel kam das Feedback viel zu spät und die Einzelteile wurden erst zum Schluss zusammengefügt – was dazu geführt hat, dass ein nicht funktionsfähiges Produkt ausgeliefert wurde.
Mit Hilfe einer solchen Deployment Pipeline erreichen wir es, dass Software per Knopfdruck released werden kann – und das jederzeit.
Der Grundgedanke hinter dieser Methode ist im Agile Manifesto passend beschrieben:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Das Ganze wird ermöglicht durch
kontinuierliche Integration,
schnelles Feedback,
Automatisierungen und
gute Tests
Ein grüner Build Status garantiert uns im besten Fall, das alles funktioniert. Diese Garantie hängt einzig von der Struktur der Deployment Pipeline und der Qualität der Tests ab. Hier können Methoden wie Testdriven Development hilfreich sein.