Continuous Integration Day auf der JAX 2013

Der Enwickler ist keine Insel – über Continuous Integration und DevOps

Judith Lungstraß

Sobald ein Entwickler sein stilles Kämmerlein verlässt und in Kontakt mit dem Markt tritt, beginnen die Probleme. War seine Arbeit vorher entweder dann erledigt, wenn er fertig war oder wenn er eben keine Lust mehr hatte, wenn er lieber einen Film schauen oder ein Computerspiel spielen wollte, muss er sich nun nach den Anforderungen der Kunden richten, auf die Bedürfnisse seiner Kollegen reagieren und möglichst effizient mit ihnen zusammen arbeiten.

Das klappt zwar nicht immer gleich gut, wird aber umso einfacher, wenn man die richtigen Taktiken verfolgt. Methoden wie Continuous Delivery und DevOps setzen an genau dieser Stelle an und sollen den Kontakt des Entwicklers zu seinem anvisierten Markt sowie zu den anderen Abteilungen seines Unternehmens verbessern. Als oberstes Ziel gilt dabei natürlich, wie immer wenn ein Produkt in der freien Marktwirtschaft verkauft werden soll, die größtmögliche Effizienz und Produktqualität bei möglichst wenig Aufwand und Kosten.

Um zum Thema Continuous Delivery zu kommen, starten wir am besten bei seinem engen Verwandten, der Continuous Integration – diesen Schritt ging auch Steffen Schuff (Orientation in Object) in seiner Session „Von Continuous Integration zu Continuous Delivery“ auf der JAX 2013.
Die kontinuierliche Integration verfolgt das Prinzip, dass der Entwickler Änderungen am Code so schnell wie möglich in die Versionsverwaltung einchecken soll, damit das Gesamtsystem in regelmäßigen Abständen basierend auf diesen Änderungen neu strukturiert werden kann.

Anfangs ein Buzzword ähnlich Continuous Delivery oder DevOps, ist Continuous Integration mittlerweile schon zum De-facto-Standard geworden – wer im Software-Sektor erfolgreich sein will, tut es.

Verfolgen wir die Ereigniskette logisch weiter, stößt Continuous Integration jedoch irgendwann an ihre Grenzen. Ist das Produkt fertig und in seiner Gesamtheit stimmig, muss es schließlich das Unternehmen verlassen und hinaus an den Kunden gehen. Hier kommt das Prinzip Continuous Delivery ins Spiel, schlägt es doch eine Brücke zwischen dem Entwickler, seinem Unternehmen und den letztendlichen Abnehmern des Produktes. Schon im agilen Manifest ist die Rede von der „continuous delivery of valuable software“ mit dem Ziel, den Kunden zufrieden zu stellen, und genau hier wurde dieser Begriff auch zum ersten Mal verwendet.

Geprägt haben ihn dann jedoch andere, nämlich Jez Humble und David Farley mit ihrem genauso betitelten Werk. Sie beschreiben Continuous Delivery als die Fähigkeit, mit möglichst wenig Risiko und Aufwand Erweiterungen sowie Bug Fixes an den Kunden liefern zu können. Dabei soll lieber häufig wenig geliefert werden als selten viel. Ebenfalls von diesen beiden Autoren stammt die sogenannte Deployment Pipeline, eine Visualisierung der Bestandteile eines Prozesses für alle daran Beteiligten. Sie beginnt stets mit der Commit-Stufe und endet mit dem Release. Was zwischen diesen beiden Endpunkten kommt, ist vom jeweiligen Unternehmen und Produkt abhängig.

Wichtig ist allerdings, dass auf allen Stufen die drei Grundprinzipien der Continuous Delivery eingehalten werden. Diese wären:

  1. Automatisierung aller Aspekte der Infrastruktur – und zwar so umfangreich wie möglich.
  2. Tests geben Sicherheit für erfolgreiche Änderungen und sind die Basis der Automatisierung.
  3. Ständiges Monitoring als Grundlage der fortlaufenden Optimierung.

An dieses dritte Prinzip schließt dann die zweite wichtige Kontaktbewegung für Entwickler an. Das Monitoring wird nämlich meist vom Operations-Sektor der Firma übernommen – er bildet das Ops in DevOps und ist dort den Devs gegenübergestellt, unter dem Deckel des Kofferwortes aber gleichzeitig auch eng mit ihnen verbunden. Continuous Delivery und DevOps hängen dicht zusammen, geht es doch in beidem Strömungen um die Vereinfachung von Release-Prozessen und Organisationsstrukturen. So könnte man sagen, dass DevOps die logische Schlussfolgerung der Continuous Delivery sind: Wer regelmäßig Produkte liefern will, muss intern gut aufgestellt sein und darf keine Kleinkriege innerhalb des Unternehmens führen. Eine erfolgreiche Auslieferung erfordert die Team-übergreifende Zusammenarbeit.

So handelt das Trendthema DevOps von der Kommunikation, Kollaboration und Integration der beiden Abteilungen Development und Operations. Nur wenn diese enger zusammen rücken und ihre unterschiedlichen Ziele – die einen wollen Veränderung und neue Features, die anderen ungefährdete Stabilität – auf einen gemeinsamen Nenner bringen können, entsteht schlussendlich ein überlebensfähiges Produkt. Davor muss aber zunächst die sogenannte Wall of Confusion überklettert werden, die zwischen den Gruppierungen in die Höhe ragt.

Peter Roßbach und Andreas Schmidt zum Thema DevOps

Eine Anleitung hierzu präsentierten Peter Roßbach (bee42 solutions) und Andreas Schmidt (Cassini Consulting) in ihrer Session mit dem bezeichnenden Titel „Feedback aus der Produktion“. Sie erzählten von den ständigen Entscheidungen, die in einem Betrieb getroffen werden müssen, etwa: „Soll eine Komponente neu gestartet werden?“, „Ist Multithreading korrekt implementiert?“ oder „Welche Variante einer Website bringt mehr Klicks?“. Zur Beantwortung dieser Fragen müssen wir Daten sammeln, Metriken erstellen – und hier liegt die wahre Herausforderung. An dieser Stelle gilt es nämlich zu analysieren, wie sich ein System verhält, wie welche Ressourcen gebraucht werden, welche Effekte Veränderungen an der Software nach sich ziehen und welche Störfaktoren die einstmals gut funktionierende Software auf dem Gewissen haben. Die Antworten, genauso wie die eventuell daraus resultierenden Optimierungsansätze, kann nur ein Zusammenspiel aus Entwicklern und Operatoren liefern.

Der Entwickler ist keine Insel – das haben auch Jörg Bächtiger (Abraxas Informatik), Urs Enzler (bbv Software Services) und Sándor Pongrácz (Abraxas Informatik) erkannt und in ihrem „Drama in 5 Akten“ zu Continuous Delivery, welches direkt nach dem Mittagessen seine Erstaufführung feiern darf, verarbeitet. Stattdessen steht er zwangsläufig in ständigem Kontakt zu seinen Mitarbeitern und Kunden. Um diesen Kontakt nicht ganz so beschwerlich zu gestalten, gibt es die Methoden Continuous Delivery und DevOps. Zu ihrem besseren Verständnis trugen auch Konstantin Diener (Cofinpro) mit seiner Session „Continuous Test Server – kontinuierliche Fachtests“ und Axel Fontaine mit seinem Vortrag über „Architecting for Continuous Delivery“ bei.

Geschrieben von
Judith Lungstraß
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.