JAX 2015: Continuous Delivery Day

Dem Server keine Namen geben – Continuous Delivery als Routine?

Moritz Hoffmann

Continuous Delivery (CD) hat als Methode in die Softwareentwicklung Einzug gehalten. Auf dem Continuous Delivery Day der diesjährigen JAX diskutierten die Referenten die Schwierigkeiten, die sich in der alltäglichen Praxis von Entwicklern ergeben und plädieren für eine konsequente und dennoch variable Umsetzung. Warum aber bleibt trotz der transparenten, automatisierten Software-Entwicklung der Produktivitätsschub aus?

Wer in der Softwareentwicklung wettbewerbsfähig bleiben will, kann um Continuous Delivery (CD) heute kaum noch einen Bogen machen. Schon im Jahr 2001 fand die Methode im Agile Manifesto Erwähnung. Kurze Zyklen von der Entwicklung zum Deployment sollen bei einem hohen und vielschichtigen Testing-Aufwand für schnelle Releases bei höchster Qualität sorgen. Die Möglichkeiten, die PaaS-Anbieter in der Cloud dazu anbieten, machen vieles einfacher, stellen Entwicklerteams aber auch vor neue Herausforderungen in puncto Datensicherheit, kostenbasierte Architektur und effiziente Deploymentmodelle.

Dabei bestärkt der entsprechende Special Day auf der JAX 2015 den Eindruck, dass viele Entwickler schon lange mit automatisierter Continuous Integration (CI), Testing und Quality Analysis (QA) arbeiten. Dem CI-Ansatz fehlt dabei lediglich das automatisierte Deployment und die Mehrdimensionalität der Testings. So ist im CD beispielsweise die User-Abnahme entscheidend, die im CI nicht vorgesehen ist. Prinzipiell aber sind CI-Elemente mit Plug-ins ergänzbar und können, wie Steffen Schluff (Orientation in Objects GmbH) in seiner Session zeigte, eine Art Sockel für die Etablierung von CD bieten.

CD, CI und DevOps

So richtig spannend für Teamprojekte werden diese permanent wiederholten Deployment-Zyklen gerade dann, wenn sie in sogenannten Pipelines visualisiert und für viele verschiedene Organisationseinheiten transparent gemacht werden. Weil hier der aktuelle Entwicklungsstand eines auf Zyklen aufgeteilten Softwareprojekts stets für alle Beteiligten einsehbar ist, sind hochautomatisierte Umgebungen in der Softwareentwicklung auch für DevOps interessant.

Allerdings scheint die dem CD letztlich zugrunde liegende DevOps-Philosophie in einer neuen Schleife festzustecken. Das hat auch Auswirkungen auf die Continuous Delivery selbst. Fast einstimmig betonten die Referenten des CD Special Days die Schwierigkeit, das „C“ im CD wirklich ernst zu nehmen, also nicht nur kontinuierlich zu liefern, sondern sich dabei auch kontinuierlich weiterzuentwickeln, um in den angebotenen Lösungen flexibel zu bleiben.

Flexibel in der Entwicklung, kontinuierlich in der Lieferung

Am Beispiel Jenkins zeigte Nigel Harniman (CloudBees), was das in der Praxis heißen kann. Jenkins hat auf die Anforderungen von Continuous Delivery in großen Organisationen reagiert und beschäftigt sich fortlaufend mit den Problemen, die die in CD an sich optimierten Ausroll-Mechanismen in einem über mehrere Organisationseinheiten verteilten Workflow mit sich bringen.

Offenkundig ist dabei auch entscheidend, welche CD-Lösung für ein Projekt überhaupt geeignet ist. So kann beispielsweise die Integration von JavaScript in ein Java-Backend, also ein duales System, dem Aufbau von Java-Parallelwelten überlegen sein, wie Dragon Zuvic (Weigle Wilczek GmbH) in seiner Session festhielt. Diese Wahl gehört zu eben der Variabilität, die sowohl CI als auch CD bietet, die aber oft nicht ausgeschöpft wird.

Rinderherden statt Hauskätzchen

Denn obwohl der DevOps-Ansatz in vielen Software-Unternehmen bereits praktiziert wird, gehören Qualitätsprobleme bei den eigenen Produkten keineswegs der Vergangenheit an. Die Routine selbst birgt immer auch das Risiko eines Innovationsrückgangs. Und so kann auch Continuous Delivery eben nicht nur strukturell oder mit neuen CD-Tools umgesetzt werden.

Wie so oft, können auch hier weiche Faktoren über den Projekterfolg entscheiden. Sowohl Axel Fontaine (Boxfuse), als auch Nigel Harniman (Cloudbees) betonten in diesem Zusammenhang den notwendigen Wandel im Verhältnis zwischen Entwickler und Produkt. Weder sollte man dem selbst aufgesetzten CI-Server einen Namen geben, noch sollten aufwendig gebaute, aber nicht funktionale Microservices oder auch Pipeline-Templates weiter im Projekt verwendet werden. Beide bemühten die Haustiermetapher: „Treat them like cattles, not like Cats. If it doesn’t work, we shoot it down.“, so Nigel Harniman.

Auch Steffen Schluff (Orientation in Objects GmbH) betonte, dass die „Wall of Confusion“ zwischen Development und Operations nicht einfach durch Automatisierung überwunden werden kann. Erst wenn das Deployment als gemeinsame Schnittstelle verstanden wird, an der gleichzeitig und jederzeit einsehbar gearbeitet werden kann, lohnt sich CI und erweitert CD auch im Rahmen von DevOps.

Geschrieben von
Moritz Hoffmann
Moritz Hoffmann
Moritz Hoffmann hat an der Goethe Universität Soziologie sowie Buch- und Medienpraxis studiert. Er lebt seit acht Jahren in Frankfurt am Main und arbeitet in der Redaktion von Software und Support Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: