Agilität trifft Stabilität: die Brücke zwischen Entwicklung und Betrieb

Schuld war nur das Internet …
Kommentare

Schon immer treffen beim Einsatz von Software die unterschiedlichen Interessen und Kulturen von Entwicklung (Development) und Betrieb (Operations) aufeinander. Der DevOps-Ansatz [1], [2] überträgt die agilen Praktiken der Softwareentwicklung auf den Betrieb und die dazugehörige Infrastruktur. Damit wird die letzte Meile erheblich verkürzt und Funktionen kommen schneller zum Anwender. Dieser Artikel zeigt, wie DevOps in der Praxis aussehen kann.

Die Softwareentwicklung hat sich in über einem Jahrzehnt kontinuierlich weiter entwickelt. Ein wichtiger Impuls dafür kam von dem vor mehr als zehn Jahren verfassten agilen Manifest. Wichtig war hier das Umdenken, dass sowohl Prozesse als auch Methoden die Softwareerstellung unterstützen statt behindern sollen. Außerdem hat lauffähige Software die höchste Priorität, damit der Nutzer diese früh anwenden und dazu Feedback geben kann. Dadurch wird die Anwendung kontinuierlich verbessert. Hilfreiche Methoden und Werkzeuge betreffen einerseits die Analyse der Kundenanforderungen, andererseits die Unterstützung der Entwickler durch Automatisierung von immer wiederkehrenden Schritten, wie testen, übersetzen und integrieren. Trotzdem war der Schritt hin zu produktiver Software oft noch weit, da der Betrieb für gewöhnlich andere Releasezyklen und Prozesse hat. Hier treffen die agilen Sprinter oft auf ITIL-Langläufer. Wie es aussieht wenn Betrieb und Entwicklung aufeinandertreffen, veranschaulicht Abbildung 1.

Kontinuität und Wandel

Der Weg von Continuous Integration zu Continuous Delivery ist ein sich lohnender, aber teilweise auch ein steiniger Weg. Um typische Stolperfallen zu vermeiden, sei das Studium des Buches „Continuous Delivery“ von Jez Humble und David Farley [3] empfohlen.

 

Abb. 1: Betrieb trifft Entwicklung

Ähnlich wie beim agilen Manifest gibt es folgende acht Prinzipien [4] für Continuous Delivery, die als Richtschnur zu betrachten sind:

  1. Wiederholbare Release- und Deployment-Prozesse
  2. Gerade das, was schwer fällt, sollte möglichst häufig versucht werden
  3. Möglichst hoher Automatisierungsgrad
  4. Alle Änderungen (Skripte, Konfigurationseinstellungen etc.) versionieren
  5. Nur was produktiv ist, kann genutzt werden
  6. Nichtfunktionale Qualitätsmerkmale berücksichtigen
  7. Jeder Beteiligte ist für den Releaseprozess verantwortlich
  8. Kontinuierliche Verbesserung

Diese Prinzipien werden um vier Continuous-Delivery-Praktiken ergänzt:

  • Binäre Artefakte nur einmal erstellen und nicht wieder aus-/einpacken
  • Für jede Umgebung denselben, parametrisierten Mechanismus verwenden
  • Smoke Test als Teil des Deployments verwenden
  • Wenn etwas schief geht, beginne von vorne ohne temporäre Hacks oder Workarounds

Agilität trifft Stabilität

Ein großes Hindernis ist oft kultureller Natur: Alle Projektbeteiligten haben unterschiedliche Interessen und Anforderungen an die Art der Softwareentwicklung. Bevor man mit Continuous Delivery beginnt, sollte man deshalb zuerst ein agiles Vorgehen und einen kontinuierlichen Integrationsprozess in der Entwicklung etablieren. Oft werden für agile Vorgehensweisen andere Skills und Rollen benötigt, als in der Organisation vorhanden sind. Ebenso ist es wichtig, dass alle Teammitglieder dafür sorgen, dass der kontinuierliche Build- und Integrationsprozess möglichst gut läuft und immer wieder optimiert wird. So können langsame Werkzeugketten oder Rechner ein schnelles Feedback verhindern. Das kann dazu führen, dass Entwickler nur selten oder nur im großen Umfang ihre Änderungen einchecken. Dadurch werden die späteren Integrationsaufwände und das Projektrisiko hingegen immer höher. Deswegen sollten sowohl in der Entwicklungs- als auch in der Integrationsumgebung dieselben Skripte und Werkzeuge eingesetzt werden, sodass ein schnelles Feedback über automatisierte Tests möglich ist. Soweit wie möglich sollten manuelle Konfigurationen vermieden werden. Neben der Codeübersetzung und -ausführung sollten auch die dazugehörigen Änderungen der Datenbank oder das Deployment auf dem Server automatisiert werden. Erst wenn diese Prozesse in der Entwicklung eine bestimmte Reife und Stabilität erreicht haben, sollte über den nächsten Schritt, die Weiterentwicklung von Continuous Integration zu Continuous Delivery, nachgedacht werden. Bei DevOps wird auch die Infrastruktur wie der eigentliche Sourcecode nach dem Motto „Infrastructure as Code“ betrachtet und mit denselben Werkzeugen und Methoden verwendet. Wichtiger als die richtigen Werkzeuge sind hier jedoch die gelebten Prozesse und das Selbstverständnis aller Beteiligten.

Vom Projekt in die Produktion

Hier kann der DevOps-Ansatz Entwicklung (Development) und Betrieb (Operations) wieder näher zusammenbringen. Beide sollten dafür gemeinsam Verantwortung übernehmen, um schneller kleiner Änderungen ohne große Beeinträchtigungen des Betriebs in die Produktion und somit zum Endnutzer zu bringen. Hier gilt der Grundsatz, dass das immer öfters und immer regelmäßiger versucht werden soll. Letztendlich geht es um eine höhere Automatisierung von wiederkehrenden Schritten, um so schneller und weniger fehleranfällige Software zu erstellen und liefern zu können. Eine Folge sind schnellere Feedback-Zyklen und die Möglichkeit, den Gesamtprozess der Softwareentwicklung vom Projekt bis zur Produktion zu optimieren.

Neben einer höheren Produktivität durch die Konzentration auf die Kerntätigkeiten ist es dadurch möglich, kleinere Änderungen an lauffähiger Software vorzunehmen. So kann der Anwender letztendlich die von ihm bestellten Funktionen schneller nutzen. Da damit Fehler schneller lokalisiert und behoben werden können, dient das DevOps-Vorgehen auch der Risikominimierung. Abbildung 2 und 3 veranschaulichen im Vergleich den Aufwand, der durch viele kleinere Releases reduziert werden kann.

Abb. 2: Höhere Frequenz

 

Abb. 3: Kleinere und häufigere Releases

Fazit

Softwareentwicklung ist nie reibungsfrei und ohne Risiken. Auch bei Continuous Integration und Delivery gibt es einige Fallstricke zu berücksichtigen und eigene Lernerfahrungen umzusetzen. Es braucht Wanderer zwischen den Welten, die beide Seiten verstehen und zwischen deren widersprüchlichen Interessen vermitteln können. Deswegen ist es wichtig, dass Entwickler Einblicke und eigene Erfahrungen im Betrieb sammeln können. Auch wenn alle Beteiligten für das erfolgreiche Release verantwortlich sind, kann es sinnvoll sein, eine neue Rolle, wie einen mit jedem Release rotierenden Releasemanager vorzusehen, der auch nach der Übergabe an den Betrieb Ansprechpartner für die in dieser Version gelieferten Funktionen bis zum nächsten Release oder der Ablösung der Software bleibt.

Das Internet hat die Art und Weise, wie wir Software entwickeln und betreiben, verändert. Firmen die diesen Trend frühzeitig erkannt haben, versuchen Entwicklung und Betrieb mit DevOps wieder enger zusammen zu bringen, um Missverständnisse zu vermeiden und die Gesamtverantwortung für den erfolgreichen Einsatz der Software über den gesamten Lebenszyklus zu erhöhen.

Links & Literatur

[1] http://en.wikipedia.org/wiki/DevOps

[2] Debois, Patrick: „Devops: A Software Revolution in the Making?“, Cutter IT Journal issue Vol 24 No 8: http://www.cutter.com/promotions/itj1108/itj1108.pdf

[3] Farley, David/Humble, Jez: „Continuous Delivery“, Addison-Wesley, 2011

[4] 8 Principles of Continuous Delivery: http://java.dzone.com/articles/8-principles-continuous

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -