Continuous Delivery in Kürze

Release auf Knopfdruck: Mit Continuous Delivery kommen Sie schneller ans Ziel.

Continuous Delivery

Das Ziel von Continuous Delivery ist die Beschleunigung der Software-Lieferkette ab dem Punkt, an dem das Entwicklerteam die Arbeiten am Quellcode abgeschlossen hat, bis zum Zeitpunkt, wo die Software tatsächlich in Produktion läuft und vom Kunden genutzt werden kann.

Erst dann kann die Software einen Wert generieren.
Continuous Delivery (CD) ist das Zusammenspiel von Rollen, Prozessen und Werkzeugen, um dieses Ziel zu erreichen.

Zusammenhang mit DevOps

Auf den ersten Blick teilen sich CD und DevOps das gleiche Ziel, allerdings hat DevOps einen deutlich größeren Blickwinkel. Das Ziel von DevOps ist die Reduzierung der Durchlaufzeit der gesamten IT-Wertschöpfungskette – von der (neuen) Geschäftsidee bis zur Nutzung des Systems und dem Feedback des Kunden zurück an das Entwicklungsteam.

Dies erfordert deutlich mehr Änderungen in der Unternehmenskultur, der Organisationstruktur und den Rollen als auch an den Software-Architekturen und schließt die Fachbereiche explizit ein. Normalerweise ist eine CD Pipeline ein Teil der DevOps-Initiative – aber DevOps ist nicht limitiert auf den Continuous-Delivery-Aspekt.

Der Bedarf für Continuous Delivery

In der Vergangenheit wurde Software in langen Releasezyklen ausgeliefert, die meiste Geschäftssoftware wurde 3-4 mal im Jahr ausgeliefert.

Dies genügt den heutigen Anforderungen nicht mehr. Der Bedarf einer schnelleren Softwarelieferung wird hauptsächlich von folgenden Punkten eingefordert:

 

  • Portfolio Management: Das richtige Produkt bauen
    • Schnellere Release-Zyklen erlauben dem Kunden, schneller und vor allem öfter Feedback an das Entwicklerteam zu geben und es damit dem Entwicklerteam einfacher machen, echten Geschäftswert zu generieren.
    • Die Verschwendung von Entwicklungs-Ressourcen für nicht gebrauchte oder falsch verstandene Features wird damit minimiert.
  • Qualitätsmanagement: Das Produkt richtig bauen
    • Durch die häufigere Lieferung in kleineren Einheiten ergibt sich automatisch eine Verbesserung der Fehlererkennung und Isolation der Fehler, außerdem wird die Reproduzierbarkeit der Fehler effizienter.
    • Durch die Einbettung der Testautomatisierung in den Lieferprozess wird die Testeffizienz gesteigert, und manuelle Fehler während der Tests werden ausgeschlossen.
  • Risikomanagement: Verbesserung der Zuverlässigkeit durch Automatisierung
    • Die Risiken, die bei großen, monolithischen Deployment-Verfahren existieren, werden durch eine reduzierte Komplexität der Deployments deutlich reduziert.
    • Deploymentverfahren sind über alle Stufen (DEV, INTE, QA, PrePROD, PROD) identisch und automatisiert und damit idempotent umgesetzt.
  • Kostenmanagement: Reduzierung der Kosten pro gelieferter Einheit
    • Kosteneinsparungen werden realisiert durch die Automatisierung aller zu wiederholenden Aufgaben in den Bereichen Entwicklung (z.B. Code-Analyse, Unit-Tests, Profiling), QA (z.B. UI-Test-Automatisierung, Performance-Tests) und Betrieb (z.B. Provisionierung, Deployment, Konfigurationsmanagement, Container-Management)

Die Grundlagen von Continuous Delivery

Der Kerngedanke von CD ist es, einen schnellen, wiederholbaren und zuverlässigen Prozess für das Bauen, Testen und Ausliefern von Software zu etablieren. Diese Automatisierung zwingt das Team dazu, alle Artefakte unter Versionskontrolle zu stellen, und zwar nicht nur die Entwickler-Artefakte, also Sourcen und DB-Scripte etc., sondern auch Infrastruktur-Definitionen und Netzwerk-Konfigurationen.

CD erfordert insbesondere, dass auf allen Umgebungen/Stages die gleichen Auslieferungsverfahren eingesetzt werden. Damit wurde ein Produktionsdeployment exakt gleich schon einmal in Dev-, Integration-, QA- und PreProd-Umgebung durchgeführt und damit das Risiko eines Fehlers minimiert.
Natürlich ist automatisiertes Testen über die gesamte Testpyramide ein integraler Bestandteil einer CD-Pipeline und sollte auf keinen Fall davon losgelöst betrachtet werden.

Wie kann Continuous Delivery umgesetzt werden?

Die klassische Continuous Delivery Pipeline

Eine CD Pipeline ist eine Menge von automatisierten Aktionen, die auf Entwickler- und Infrastruktur-Elemente angewendet werden.
Jede Aktion wird dabei von einem ebenfalls automatisierten Validierungsschritt abgeschlossen.
Wenn die Validierung erfolgreich ist, transportiert die Pipeline die Artefakte zur nächsten Stufe, falls nicht, wird die Pipeline “angehalten” und ein Fehler über das Monitoring-System an das Team gesendet.

Eine typische CD Pipeline besteht aus den folgenden Bausteinen und Prozesselementen:

  • Ein (häufig verteiltes) Versionskontrollsystem zur Speicherung aller Artefakte und zum Verfolgen der Änderungen
  • Ein Continuous Integration Server, der getriggert durch die Commits im Versionskontrollsystem die Builds und Tests der Developer-Artefakte durchführt, typischerweise kombiniert mit einer statischen Code-Analyse
  • Ein Artefakt-Repository, das die gebauten Binär-Artefakte speichert und deren Abhängigkeiten verwaltet
  • Eine Umgebung, um automatisiert Regressionstest auszuführen, die schnelle, wiederholbare und parallele Testausführung erlaubt, meist auch geeignet für Performance-Tests und kombiniert mit einem Testdatenmanagement.
  • Eine Automatisierung der Provisionierungs- und Deployment-Prozesse, die das Packaging und das Ausrollen auf saubere, klar definierte Umgebungen erlaubt und auch Themen wie Abhängigkeitsmanagement und das Konfigurationsmanagement für die Umgebungen und Applikation beinhaltet.
  • Ein Release-Management, das die verschiedenen Bausteine der CD Pipeline zusammenfügt und einen durchgängigen Prozess sicherstellt sowie optional auch die Möglichkeit bietet, automatisierte und (noch vorhandene) manuelle Prozesse abzubilden.

Continuous Delivery mit Containern und Pull statt Push

Schematische Abbildung einer CD Pipeline mit Docker (Quelle: https://blog.docker.com/2016/04/cicd-with-docker-cloud/)

continuous_delivery_2

Der Siegeszug von Containern wie z.B. Docker und deren Schedulern gibt einem anderen Paradigma einen deutlichen Anschub.

Während die klassische CD Pipeline die Systeme, Einstellungen und Artefakte auf die Zielumgebungen pusht, finden wir bei dem anderen Ansatz einen Pull-Mechanismus vor:

  • Die klassische CD Pipeline wird weiterhin genutzt, das Ergebnis sind vollständig getestete, unveränderliche (immutable) Container Images, die in einer Container-Registry gespeichert werden.

  • Die verschiedenen Umgebungen und Stufen bis hin zur Produktion sind als Scheduler-Konfigurationen abgebildet
  • Um ein System in einer bestimmten Stufe zu betreiben, übergibt man dem Scheduler eine Konfiguration, die den gewünschten Zustand der Zielumgebung beschreibt (Desired State Configuration)<
  • Der Scheduler holt sich (pullt also, daher der Name) alle benötigten Images aus der Container-Registry, startet die Umgebung wie gewünscht und überwacht deren Zustand
continuous_delivery_3

Beispiel einer Pull-basierten CD Pipeline mit dem Scheduler Mesos. http://container-solutions.com/continuous-delivery-with-docker-on-mesos-in-less-than-a-minute-part-2/

Das Ganze hat den Vorteil, dass das eigentliche Deployment der Artefakte losgelöst ist von den Ressourcen, die zur Laufzeit benötigt werden. Damit ist die Bereitstellung und Nutzung von Ressourcen deutlich flexibler, weil die Zielsysteme und deren Ressourcen nicht statisch bereitgestellt werden müssen, sondern dynamisch und elastisch durch den Scheduler genutzt werden können. Der Scheduler muss natürlich weiterhin mit dem Konfigurationsmanagement verbunden sein.

Außerdem muss man sich darauf einstellen, dass in absehbarer Zeit zumindest in größeren Unternehmen die klassische und die Pull-basierte CD Pipeline parallel existieren werden und evtl. Abhängigkeiten zwischen beiden Prozessen gemanaged werden, solange noch nicht alle Abteilungen containerbasiert weitestgehend unabhängige Services entwickeln.

Werkzeug-Auswahl

Für jeden Teilbereich der CD Pipeline gibt es zahlreiche Werkzeuge, aus denen man wählen muss. Die Spanne reicht von sehr guten Open-Source-Werkzeugen über Mischformen (Freemium-Modell) bis hin zu rein kommerziellen Werkzeugen. Es ist wichtig, die Werkzeuge so auszuwählen, dass sowohl eine reibungslose Zusammenarbeit gegeben ist als auch alle heute genutzten Zielplattformen unterstützt werden.

Das folgende Bild gibt einen guten Eindruck über die Vielfalt der möglichen Werkzeuge (Stand Sommer 2016), das Bild wurde uns freundlicherweise von unserem Partner XebiaLabs bereitgestellt:

Continuous Delivery muss ständig verbessert werden

Der Aufbau einer CD Pipeline ist keine einmalige Sache, sondern die Pipeline unterliegt einer ständigen Optimierung. Das externe Wissen über die Methoden, Verfahren und Werkzeuge ändert sich ständig – genauso wie die interne Erfahrung mit der Pipeline.

Deswegen ist es notwendig, die CD Pipeline ständig an neue Anforderungen anzupassen und die Implementierung sowie die Bausteine auf dem technologisch optimalen Stand zu bringen. Das ist nicht nur die Aufgabe eines Experten-Teams, sondern Aufgabe aller Nutzer der CD Pipeline – also Entwickler, Tester und Betrieb.

Nehmen Sie Kontakt mit uns auf.

Kontaktieren Sie uns

Kontakt:

Matthias Zieger
Business Development DevOps & Continuous Delivery

Zum Experten-Profil

Das könnte Sie auch interessieren

ZUKUNFTSWEISENDE TECHNOLOGIEN

Produktiver mit XebiaLabs

CONTINUOUS DELIVERY

Artefaktverwaltung mit Artifactory oder Nexus

CONTINUOUS DELIVERY

Continuous Integration