Agile Praktiken können in zwei Kategorien eingeteilt werden: Rezepte und Fühler (Sensoren). Menschen mit sehr viel Erfahrung in der Entwicklung von Software haben diejenigen Praktiken beschrieben, welche für die höchste Produktivität sorgen. Zusätzlich entlarven diese Vorgehensweisen Probleme im Prozess, indem unproduktives Handeln sichtbar gemacht wird.

Continuous Delivery ist sowohl Teil der agilen Rezepte, als auch ein Fühler für ineffizientes Vorgehen. Weiterhin muss man durch alle Phasen des Entwicklungslebenszyklus agil bleiben, um alle Vorteile von agiler Entwicklung zu haben. Iteratives Planen und Vorgehen bringt herzlich wenig, wenn Ihre User Stories und Bugfixes ewig in irgendwelchen Repositories verweilen, bevor sie ein Stakeholder oder Kunde zu Gesicht bekommt.

Die Essenz von agiler Entwicklung ist „Untersuchen und Anpassen“. Das bedeutet nicht, dass man nun sein Build- und Deploymentsystem unter die Lupe nehmen muss, um herauszufinden, ob es dem Team bei agilem Vorgehen hilft oder nicht. Der vorliegende Artikel von Ian Buchanan von Atlassian beschreibt unter der Annahme, dass Sie Ihr System als hinderlich identifiziert haben, Wege der Anpassung an moderne, agile Gegebenheiten. Zeit, sich der Anpassung zu widmen.

Ein Leben mit Continuous Frustration

Es gibt einen Zustand in der Softwarewelt den man getrost mit “continuous frustration” umschreiben kann. Es ist die komplette Abwesenheit jeglicher Continuous Integration- und Delivery-Praktiken. Das Ganze fühlt sich dann ungefähr so an:

  • Mit jedem Commit nach master schwingt die Angst einer Schuldzuweisung mit.
  • Der mainline-Code ist ständig instabil.
  • Bugs verstecken sich in Unmengen von Code-Änderungen und die Motivation, sich überhaupt auf die Suche nach dem Fehler zu begeben (geschweige denn diesen zu beheben) tendiert gegen Null, da der Code das letzte Mal vor Jahren angefasst wurde.
  • Wenn Tester ein Feature testen möchten, müssen diese alle Entwickler nerven, um auf den aktuellen Stand gebracht zu werden und einen funktionierenden Build zu finden.
  • Veröffentlichen kann nur mithilfe eines berüchtigten „Code Freezes“ bewerkstelligt werden. Jemand wird zum künstlichen Flaschenhals und hat die Aufgabe, das Release stabil zu machen. In der Zwischenzeit hört niemand wirklich auf zu arbeiten. Sobald der Freeze aufgehoben wird, rollt eine Lawine aus ungetestetem Code ins Repository und erzeugt wochenlang Probleme.

Falls Ihnen das bekannt vorkommt – es gibt Hoffnung.

Denken Sie an „Untersuchen und Anpassen“. Genau wie dieses Vorgehen den Planungsprozess verbessern kann, so kann dies auch auf Entwicklung und Auslieferung angewandt werden. Man stelle sich vor, Probleme ließen sich bereits an der lokalen Workstation entdecken – bevor überhaupt ein Commit getätigt wurde. Das ist der Grund, weshalb agiles Vorgehen Continuous Delivery benötigt: Entwickler sind auf schnelles Feedback angewiesen.

Das Großartige an Continuous Delivery: man muss es niemandem verkaufen, und niemand benutzt Technologien, die so einzigartig sind, dass die grundlegenden Praktiken, Prinzipien und Werkzeuge von Continuous Delivery nicht angewandt werden können.

Anfangen mit einem Script und Server…

In der Vergangenheit gab es nur Make und viele Whitespace-Bugs. Mit Ant gab es spitze Klammern. Jetzt ist es möglich, die vorigen Generationen hinter sich zu lassen. Sicher, es gibt noch eine Vielzahl von Projekten mit Maven oder Ant als Buildsystem, aber XML-basierte Buildsysteme sollten nur noch als Fallback-Option betrachtet werden.

Die neuste Generation von Buildsystem ist viel einfacher zu lernen und benutzen. In den meisten Fällen kann man eine Build-Sprache verwenden, die in der gleichen Programmiersprache wie das Projekt verfasst ist. Dies macht einiges leichter für Sie und Ihr Team.

Programmiersprache Empfohlenes Werkzeug
Java Gradle
C, C++ CMake
.NET psake
PHP Robo
JavaScript Grunt
Python Paver
Ruby Rake
Perl Module::Build
Objective-C Bash
GoLang Make

 

Der „Continuous“-Teil von Continuous Delivery heißt, Feedback für jeden Commit zu bekommen. Aus diesem Grund lauschen Build-Server automatisch auf Änderungen in Repositories und lösen einen Build aus, wenn sich etwas ändert. „Continuous“ heißt ebenfalls, den Build zu reparieren, falls dieser fehlschlägt. Als Entwickler profitiert man ebenfalls von isolierten Änderungen. Die beste Methode, um Bugfixes einfach zu halten lautet, zu verhindern, dass sich diese überhaupt erst ansammeln. Build-Server wie Atlassian Bamboo sind dafür geeignet. Anfangs besteht ihr Zweck darin, lediglich Build Scripts in einer sauberen Umgebung auszuführen. In gewissem Sinne hilft ein Build Server also dabei, Probleme in Ihren Buildscripts aufzudecken.

… um dann Probleme automatisch zu erkennen

Ein Build-Server kann weit mehr Probleme als Syntaxfehler im Build Script aufdecken. Da gibt es einfache Dinge, wie Compiler-Warnungen anschalten oder komplexere Dinge, wie automatisierte Tests. Manuelles Testen ist stets ein Flaschenhals für Continuous Delivery. Die Kunst besteht anfangs darin, die Ebene zu finden, auf welcher man durch Automatisierung das schnellste Feedback erhält; Unit-, Integration,- Akzeptanz- oder UI-Tests sind solche Kandidaten.

Automatisiertes Testen ist keine Bedrohung für manuelle Tester. Menschliche Tester sind wunderbar geeignet, um herauszufinden, welche Tests automatisiert werden können – und welche nicht. Eine kluge Strategie zur Automatisierung beruft sich auf die Frage, „Welche Probleme sind die wertvollsten, die wir aufdecken können?“. Um diese Frage beantworten zu können, benötigt man erfahrene Menschen.

Die Saat von Continuous Delivery pflanzen

Jetzt liegt es an Ihnen, die Saat von Continuous Delivery in Ihrem Team zu pflanzen. Es gibt viele Gründe, mit Continuous Delivery anzufangen. Lesen Sie mehr dazu auf unseren Lösungsseiten oder dem Artikelarchiv. Der nächste Artikel befasst sich damit, wie Continuous Delivery und Git zusammen funktionieren können.

Das interessiert Sie?

Dann sind wir als Atlassian Platinum Partner für Sie da.

[/jbox]