Partner von:

"Continuous Delivery macht die Software-Entwicklung entspannter"

Tastatur Laptop IT Computer Keyboard freeimages [Quelle: freeimages.com, Autor: Greenbay]

Quelle: freeimages.com, Greenbay

Die Software möglichst schnell an den Mann, das heißt an den Kunden bringen, das ist das Ziel von 'Continuous Delivery'. Dr. Stefan Wolf von TNG Technology Consulting erklärt im Interview, wieso das Entwickeln so entspannter wird, obwohl alle mehr auf Qualität achten müssen.

Was versteht man unter Continuous Delivery?

Continuous Delivery ist eine Sammlung von Best Practices, um die Software möglichst schnell vom Entwickler zu den Nutzern zu bringen. Continuous Delivery geht dabei weiter als Continuous Integration, weil es den ganzen Weg der Software betrachtet. Bei Continuous Integration geht es nur darum, dass automatisch Tests durchgeführt werden, die sicherstellen, dass die bisherige Funktionalität durch die Änderungen nicht beeinträchtigt wird. Die Tests laufen ab, sobald der Entwickler mit einem Teilabschnitt fertig ist und diesen in die Versionskontrolle einspielt. Das Ziel ist es, dass die eingecheckte Software immer lauffähig ist. Continuous Delivery kommt aus der Ecke der agilen Entwicklung.

Wo kann man Continuous Delivery "lernen"?

Es gibt keine Spezialkurse und Zertifkate wie zum Beispiel bei Scrum, man muss es einfach machen. Man nimmt sich einfach vor, den Weg vom Programmierer zum Nutzer zu kürzen und packt da an, wo es wehtut.

Wo tut es denn zum Beispiel besonders weh?

Ein Grundprinzip von Continuous Delivery ist, möglichst oft zu releasen. So bringt man die Features möglichst schnell an den Mann. Das hat auch den Vorteil, dass weniger Risiken entstehen - wenn man alle zwei Wochen releast, weiß man noch genauer, welche Features man in den letzten zwei Wochen entwickelt hat. Man hat einen guten Überblick über die Software und findet Fehler schneller. Wenn man zum Beispiel nur jedes halbe Jahr realeast, sieht das schon anders aus. Große, schnelle Internet-Unternehmen wie LinkedIn und Facebook releasen mehrmals täglich. Oft machen sie Features auch erst nur für einen Teil der Nutzer sichtbar, um herauszufinden, wie das Feature ankommt.

Was kann man heutzutage in der Software-Entwicklung machen, damit jede Änderung am Code automatisch übernommen wird?

Das fängt schon beim Entwickeln an: Man sollte viele automatisierte Tests einbauen, die die grundlegende Qualität der Software sicherstellen. Erst wenn die automatisierten Tests durch sind, gibt man die Software an die Qualitätsmanager weiter. Zu diesem Zeitpunkt muss die Software schon vernünftig benutzbar sein, und das GUI, also die Benutzeroberfläche, funktionieren wie geplant. Ein weiteres Prinzip von Continuous Delivery ist, dass man alles automatisieren sollte, was man öfter als zwei Mal macht. Auch das Ausrollen und der Roll-back sollten automatisch funktionieren.

Man muss jeden Schritt automatisieren und da auch Zeit reinstecken. Wenn irgendwas wehtut, das heißt nicht funktioniert, sollte man es öfter machen, um herauszufinden, worin der Fehler liegt. Wenn man nur alle sechs Monate deployed und das schlecht funktioniert, sollte man es jeden Monat machen. Vielleicht ist das Deployment so kompliziert, weil es viele manuelle Schritte gibt, bei denen man leichter Fehler macht. Oder man weiß nicht so genau, was kaputt gegangen ist, weil die einzelnen Schritte zwar dokumentiert sind, aber nicht festgehalten wird, was man wirklich gemacht hat.

Damit alles relativ automatisch funktioniert, sollte man keine manuellen Tests einbauen. Zumindest sollten aber die Regressionstests automatisch laufen - dann muss man nur den neu entwickelten Code testen.

Worauf muss man beim Erstellen von Akzeptanztests und automatisierten Tests achten?

Man sollte sich an die agile Testpyramide halten. Die besagt, dass es viele Unit-Tests geben soll, einige Integrationstests und nur wenige Akzeptanztests. Unit-Tests testen nur einen ganz kleinen Teil der Software und können schnell durchgeführt werden. Sie werden von den Entwicklern geschrieben, wie auch die Integrationstests, die mehrere Komponenten und ihr Zusammenspiel betreffen.

Die Akzeptanztests wiederum prüfen das ganze Feature bis zum Ende und werden manuell ausgeführt. Sie sind daher langsamer und eventuell fragiler. Auch die Usability wird dabei getestet. Die Akzeptanztests sollten von der Qualitätssicherung geschrieben werden, nicht vom Entwickler selbst. Denn oft hat man zu sehr die Entwicklerbrille auf und weiß schon gar nicht mehr, ob die Software den eigentlichen Anforderungen der Kunden entspricht. Wichtig ist bei allen Tests, dass sie leicht zu warten sind.

Eine weitere nützliche Regel ist, dass man generell den Code erst dann entwickelt, wenn man zuvor einen Test dafür geschrieben hat. So stellt man auch sicher, dass man keine Funktionen vergisst. Das Gleiche gilt, wenn man einen Bug behebt. Auch da sollte man erst den Test für den Fehler schreiben und dann erst den Bug fixen - so tritt er nicht noch einmal auf.

Wie werden größere Features ausgeliefert, die viele Sprints umfassen?

Gemäß Scrum ist es ja so, dass jede User-Story in einen Sprint passen muss, sonst kann man das Feature nicht mit Scrum-Entwicklung umsetzen. Es kann natürlich immer sein, dass man ein Feature auf mehrere User-Storys aufteilen muss. Dann will man dem User natürlich nicht das unfertige Feature zeigen. Für solche Fälle gibt es das Feature-Flag: Man kann die Software zum Deployment konfigurieren, sodass gewisse Features aktiv sind oder eben nicht. Wenn ein Feature also zu groß ist für einen Sprint, dann ist es in der Testumgebung schon aktiv, damit die Kollegen der Qualitätssicherung es sich ansehen können. Der Nutzer aber sieht das Feature noch nicht. Auch das Ausrollen eines Features für nur einen Teil der Nutzer passiert per Feature-Flag.

Wie steht es um die Rollback-Möglichkeit beim Deployment?

Es kommt drauf an, wie oft man releast. Wenn man häufig releast, kann man leichter einen Rollback machen. Denn dann kann man die Änderungen rückwärtskompatibel halten. Der Rollback sollte automatisch sein, aber auch die Möglichkeit zum manuellen Eingreifen bieten. Denn es kann zum Beispiel sein, dass man anhand gewisser Trendgrafiken Probleme sieht, die das automatische System gar nicht analysieren kann und deswegen auch keinen Rollback starten würde. Wenn man längere Release-Zyklen hat, dann sollte man natürlich auch eine Rollback-Möglichkeit haben, die kann aber auch manuell sein. Denn in solchen Fällen wird man sowieso eine Downtime haben, in der der Service nicht erreichbar ist.

Was bedeutet "Infrastructure-as-code"?

Früher war es oft so, dass jemand einfach einen Server so installiert hat, wie er das für richtig gehalten hat. Allerdings kann man feststellen, dass bei der Installation immer wieder die gleichen Fehler begangen werden: Es fehlen spezielle Zertifikate, oder ein bestimmter Schritt bei der Java-Installation. Daher ist man dazu übergegangen, das komplette Aufsetzen der Maschine zu automatisieren. Das nennt sich dann "Infrastructure-as-code": Die Infrastruktur ist als Code hinterlegt.

Wie stellt man sicher, dass die Zusammenarbeit von Entwicklung und Quality Assurance gut funktioniert?

Da wird ein Prinzip von Continuous Delivery aktiv: Die Qualität muss von Anfang an eingebaut werden, und das betrifft alle Beteiligten. Nicht nur die Qualitätssicherung (QA) ist zuständig für Qualität, sondern auch die Entwickler. Die Entwickler können der QA nicht einfach ihre Software "hinschmeißen", sondern müssen mit ihr zusammenarbeiten, zum Beispiel indem sie automatisierte Tests entwickeln. Wenn die abgeschlossen sind, hat die Software daher schon eine bestimmte Qualitätsstufe erreicht, erst dann schaut die QA drauf. Ziel ist ja, dass nach jedem Check-In ein Release möglich sein soll, also können die Entwickler nicht einfach Code einchecken, der nicht von Tests abgedeckt ist oder der die Hälfte des Systems kaputt macht. Das Silodenken muss man ablegen, man sollte nicht versuchen, gegeneinander zu arbeiten.

Was bedeutet Continuous Delivery fürs ganze Team? Wird die Arbeit stressiger, weil sich jeder so viel um die Qualität kümmern muss?

Eigentlich wird die Entwicklung mittels Continuous Delivery entspannter, weil man durch die Testabdeckung sofort weiß, ob die neu entwickelte Software funktioniert. In der Firma, in der ich aktuell auf Projekt bin, war es zum Beispiel früher so, dass sich nur einer im Team ums Deployment gekümmert hat und sich damit auskannte. Dokumentationen sind ja immer etwas schwierig, und wenn besagter Mitarbeiter im Urlaub war, dann haben sich die anderen nicht ans Deployment rangetraut.

Jetzt haben wir die Release-Zyklen verkürzt, und daher ist alles entspannter. Denn mittlerweile haben alle Mitarbeiter aus dem Team schon mal ein Release gemacht, und außerdem wird das Deployment auch automatisch getestet. Früher hat man sich für das Release am Wochenende einen halben Tag reservieren müssen, jetzt geht das viel schneller und demzufolge weniger stressig. Und auch die Wahrscheinlichkeit für Fehler ist geringer. Als wir bei diesem Kunden mit dem Projekt angefangen haben, gab es noch keine automatisierten Tests, nicht einmal der Build, also der Aufbau einer Software-Version, die releast werden kann, war automatisiert. Inzwischen haben wir eine vierstellige Zahl von Tests und können das Deployment per Knopfdruck starten.

nach oben
Kommentare (0)

Zum Kommentieren bitte einloggen.

Das könnte dich auch interessieren