Best Practices für mehr Software-Qualität

Was zeichnet „gute“ Continuous Delivery aus?

| Autor / Redakteur: Brian Dawson * / Stephan Augsten

Wachsam sein: Bei CD ist die Fähigkeit, Bewegungen von Änderungen durch das System zu verfolgen, von entscheidender Bedeutung.
Wachsam sein: Bei CD ist die Fähigkeit, Bewegungen von Änderungen durch das System zu verfolgen, von entscheidender Bedeutung. (© Coloures-Pic - stock.adobe.com)

Wer die Prinzipien von Continuous Integration befolgt, ist bereit für Continuous Delivery, kurz CD. Doch ähnlich wie bei der kontinuierlichen Integration glauben viele Unternehmen, dass sie mit CD viel besser zurechtkommen, als es in der Realität der Fall ist.

Continuous Integration ist ein automatisierter Prozess, der vom Entwicklungsteam praktiziert wird. Entwickler übertragen dabei häufig Quellcode-Änderungen in ein zentrales Repository. All diese Änderungen werden kontinuierlich umgesetzt und validiert.

Auf diese Weise ist es möglich, Fehler schnell und früh zu entdecken und zu beheben. Ein Mantra von CI ist: „Scheitere schnell“. Diese Vorgehensweise beschleunigt den Entwicklungsprozess und trägt dazu bei, eine hohe Code-Qualität zu gewährleisten.

Continuous Delivery erweitert die CI-Prinzipien und -Praktiken in der Software-Auslieferung „nach rechts“ (downstream) – durch kontinuierliches Testen und die Bereitstellung von Code für verschiedene Konsumenten des Codes. So soll sichergestellt werden, dass sich die Software bei jeder Änderung in einem Release-fähigen Zustand befindet.

Continuous Delivery zwischen Anspruch und Wirklichkeit

Mit CD lassen sich Änderungen schnell, reproduzierbar und zuverlässig in die Vorproduktions- oder Produktionsumgebungen und schließlich in die Hände der Anwender bringen. Wie Continuous Integration ermöglicht CD den Entwicklerteams, „schnell zu scheitern“, auf Basis von Feedback aus der Praxis diese Fehler schneller zu beheben und damit den Nutzen für den Kunden zu steigern.

Entsprechend erhält CD in der Branche viel Aufmerksamkeit. Nachdem das Buch von Jez Humble und Dave Farley den Begriff 2010 populär gemacht hat, zeigten Tech-Unternehmen wie Netflix und Flickr, wie sie mit Continuous Delivery Dutzende von Deployments pro Stunde erreichen können.

Man könnte meinen, dass viele Organisation dem Beispiel dieser Best Practices gefolgt sind. Doch die Zahlen zeigen ein sehr unterschiedliches Bild: Laut dem DZone 2016 Guide to Continuous Delivery glaubt die Hälfte aller befragten Fachleute, dass sie die CD-Praxis befolgen, aber nur zehn Prozent taten dies tatsächlich, basierend auf den folgenden drei Fragestellungen:

1) Ist die Software nach jeder Änderung in einem Release-fähigen Zustand?

Wenn eine Organisation sicherstellt, dass sich die Software immer in einem Release-fähigen Zustand befindet, dann wird sie mit ziemlicher Sicherheit kontinuierlich ausgeliefert.

2) Haben alle Beteiligten Einblick in die Release-Fähigkeit der Software?

Wenn eine Organisation kontinuierlich erfolgreich Software entwickelt, testet, bewertet und ausliefert, scheint dieser Punkt vielleicht nicht ausschlaggebend. Jedoch die Transparenz des Prozesses für alle stellt das Vertrauen zwischen Dev und Ops her, was wiederum die Automatisierung des Prozesses ermöglicht. Die Sichtbarkeit unterstützt auch wichtige Feedback-Schleifen.

3) Kann ein Deployment jederzeit per Knopfdruck durchgeführt werden?

Dieser Punkt basiert auf dem CD-Prinzip, dass das Deployment ein „Non-Event“ sein sollte, da die Software immer in einem Release-fähigen Zustand ist – vorausgesetzt, sie wurde in einer Produktionsumgebung und in einem Deployment-Prozess getestet.

Strenge Definitionen von CD besagen, dass Teams, die wahres CD praktizieren, in der Lage sein sollten, all diese Fragen positiv zu beantworten. Die folgenden Punkte verstehen sich als Handlungsanweisung für Unternehmen, die in ihrer Organisation Nachholbedarf in Sachen CD vorweisen:

  • Ausmaß der Änderungen regulieren: Einer der ersten Schritte besteht darin, Änderungen so auszudrücken, dass sie schnell durch die CD-Pipeline geliefert werden können. Das unterstützt nicht nur den Automatisierungsgrad beim Testen und minimiert Fehler, sondern stellt auch den tatsächlichen Mehrwert jeder Änderung für den Kunden in den Fokus. Agile Methoden wie Kanban oder Scrum können hier unterstützen.
  • Tracking-System nutzen: Bei CD ist die Fähigkeit, Bewegungen von Änderungen durch das System zu verfolgen, von entscheidender Bedeutung. Mit einem Tracker wie Bugzilla oder Jira können alle Verantwortlichen über den gesamten Delivery-Prozess hinweg zusammenarbeiten und wichtige Key Performance Indicators (KPIs) messen, bspw. die Zykluszeit einer Änderung.
  • Versionskontrollsystem implementieren: Die Versionskontrolle ermöglicht es Teams, jederzeit zu verstehen, was sich in der Codebasis geändert hat. Dies erlaubt gegebenenfalls ein schnelles Zurückrollen. Moderne Versionskontrollsysteme wie Git bieten kollaborative Funktionen wie z.B. Pull-Requests an, die die Qualität durch ein Peer-Auditing erhöhen.
  • Deployment des Builds automatisieren: Um einen Build in den Downstream zu bringen, ist es wichtig, das Deployment des Builds in einer Umgebung wie der, in der er ausgeführt werden soll, zu automatisieren. Ein wichtiger Aspekt dabei ist nicht nur die Funktion des Deployments, sondern auch der Zugriff auf die entsprechende Infrastruktur und Umgebung. Während dieser Prozess in der Vergangenheit relativ statisch war, brauchen Teams heute aufgrund der hohen Geschwindigkeit von Änderungen in CD-Pipeline, sofortigen und konstanten Zugriff auf die Umgebungen.
  • Deploy in eine produktionsähnliche Umgebung: Der Zugang zu den produktionsähnlichen Umgebungen muss in der Pipeline so früh wie möglich gegeben sein – idealerweise bereits in der Entwicklung. Wird Software in anderen Umgebungen eingesetzt, bleibt für das Deployment immer ein gewisser (negativer) Überraschungsfaktor. Entwickler können dann nicht behaupten, dass sich die Software immer in einem Release-fähigen Zustand befände. Eine Möglichkeit, dies zu erreichen, besteht darin, die Infrastruktur als Code- oder Konfigurationsmanagementlösung zu verwenden, um die Produktionsumgebung zu definieren. Dieselbe Konfiguration wird sodann genutzt, um die Vorproduktionsumgebungen für Entwicklung, Test und Stage zu definieren.
  • Arbeiten mit Binärdateien, nicht mit dem Quellcode: Viele Organisationen arbeiten auch in CD-Projekten am Quellcode selbst. Dabei wird die Software in jeder Phase neu erstellt. Dieses Vorgehen widerspricht den CD-Richtlinien, ist jedoch ein häufig zu beobachtendes Phänomen. Jedes Mal, wenn eine Version der Software direkt vom Quellcode erstellt wurde, steigt die Chance, dass Fehler auftreten und/oder übersehen werden. Mögliche Unterschiede in Build-Skripten, Umgebungen usw. machen Upstream-Tests und Validierungen nicht mehr vertrauenswürdig. Der richtige Ansatz ist, einmal den Code zu bauen und fortan dann diese Binärdateien im weiteren Verlauf zu nutzen. Dadurch wird sichergestellt, dass jeder Folgeschritt auf der Freigabe von früheren Versionen aufbaut.

Brian Dawson
Brian Dawson (Bild: CloudBees)

Continuous Integration ist eine Vorstufe zu Continuous Delivery. Wer CI und CD nicht richtig einsetzt, profitiert nicht vom geschäftlichen Mehrwert, den diese Prozesse mit sich bringen: schnellere Time-to-Market, einen gesteigerten Wettbewerbsvorteil, bessere Softwarequalität und höhere Mitarbeiterzufriedenheit.

* Brian Dawson ist DevOps Evangelist bei CloudBees.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45254008 / CI / CD)