Close

Continuous Delivery

Continuous Delivery (CD) ist eine Methode, bei der Software mithilfe von Automatisierung in kurzen Iterationen freigegeben wird

Was ist Continuous Delivery?


Continuous Delivery ist ein Ansatz, bei dem Teams regelmäßig, vorhersagbar und automatisch Qualitätsprodukte vom Quellcode-Repository zur Produktion bringen.

Wie im folgenden Diagramm dargestellt veröffentlichen manche Unternehmen Produkte manuell, indem sie sie von einem zum nächsten Team weiterreichen. Üblicherweise stehen Entwickler ganz links in dieser Kette und Operations-Mitarbeiter am Ende. Das sorgt für Verzögerungen, die Teams frustrieren und die Zufriedenheit der Kunden beeinträchtigen. Bis das Produkt schließlich veröffentlicht wird, haben alle einen mühsamen und fehleranfälligen Prozess durchlaufen, der die Umsatzgenerierung verlangsamt hat.

Abbildung 1: Manueller Release von Produkten an Kunden
Ablauf manueller Release: Entwicklung, QA, Tools, Infrastruktur, Plattform, Release, InfoSec

Sieh dir nun die Continuous-Delivery-Pipeline unten an. Hier schreiben Entwickler Code auf ihren Laptops und committen Änderungen an ein Quellcode-Repository, wie etwa Bitbucket. Wenn wir von Code sprechen, meinen wir das zu testende System, die Tests und die Infrastruktur, mit der das System bereitgestellt und verwaltet wird. Mit Bitbucket Pipelines kannst du ein Produkt von der Test- zur Staging- und schließlich in die Produktionsumgebung ausliefern, damit sich deine Kunden über die tollen neuen Features freuen können.

Abbildung 2: Continuous Delivery-Pipeline mit automatischen Releases
Ablauf Continuous-Delivery-Pipeline: Entwickler, Laptop, Bitbucket, Bitbucket Pipelines, Kunden

Wie funktioniert Continuous Delivery?


Bei einer Continuous Delivery-Pipeline kann es direkt vor der Produktion ein manuelles Gate geben. Manuelle Gates erfordern das Eingreifen eines Menschen. Möglicherweise gibt es in deinem Unternehmen Szenarien, in denen manuelle Gates in Pipelines nötig sind. Manche dieser Gates sind fragwürdig, andere wiederum legitim. Bei einem legitimen Szenario kann z. B. das Unternehmensteam eine Entscheidung in letzter Minute treffen. Das Entwicklerteam hält nach jedem Sprint eine auslieferbare Version des Produkts bereit und das Unternehmensteam beschließt in letzter Instanz die Veröffentlichung des Produkts für alle Kunden, eine bestimmte Personengruppe oder etwa ein bestimmtes geografisches Gebiet.

Die Architektur des Produkts, das die Pipeline durchläuft, ist ein wichtiger Faktor, nach dem sich die Anatomie der Continuous Delivery-Pipeline richtet. Bei einer hochgradig gekoppelten Produktarchitektur ergibt sich ein kompliziertes grafisches Pipeline-Muster, in dem mehrere Pipelines auf komplexen Wegen schließlich zur Produktion führen.

Außerdem beeinflusst die Produktarchitektur die verschiedenen Phasen der Pipeline und bestimmt, welche Artefakte in einer Phase erstellt werden. In der Pipeline werden zunächst Komponenten entwickelt – die kleinsten Einheiten oder Units eines Produkts, die sich verteilen und testen lassen. Eine Komponente kann zum Beispiel eine Bibliothek sein, die in der Pipeline erstellt wird. Wir sprechen hier von der Komponentenphase.

Lose miteinander verbundene Komponenten bilden zusammen ein Subsystem, d. h. die kleinsten bereitstellbaren und ausführbaren Einheiten. Ein Server ist beispielsweise ein Subsystem. Auch ein in einem Container ausgeführter Mikroservice ist ein Beispiel für ein Subsystem. Wir nennen es die Subsystemphase. Im Gegensatz zu Komponenten können Subsysteme überprüft werden.

Du kannst die in der Pipeline lose verbundene Subsysteme auch zu einem einzigen System zusammenfügen, wenn es das Ziel ist, ein ganzheitliches System zu veröffentlichen. Das ist die Systemphase.

Wir raten dir davon ab, Subsysteme zu einem System zusammenzuführen. Schaue dir hierzu Abbildung 3 an.

Abbildung 3: Subsysteme, die zu einem System zusammengeführt werden
Diagramm: Subsystem

Mit diesem Alles-oder-nichts-Ansatz wird selbst das schnellste Subsystem maximal verlangsamt. Daher warnen wir Teams, die den Versuchungen dieses Architekturmusters erliegen, denn jede Kette kann nur so stark sein wie ihr schwächstes Glied.

Nachdem das zusammengeführte System geprüft wurde, wird es ohne weitere Änderungen an die Produktion übermittelt. Diese letzte Phase nennt sich Produktionsphase.

Die Phasen sind eher eine logische als eine tatsächliche Unterteilung. Mithilfe von Phasen kannst du ein großes Problem in viele kleinere Teilprobleme aufsplitten. Abhängig von der Architektur und deinen Anforderungen gibt es entsprechend mehr oder weniger Phasen.

Unseren Kunden ist mit einer schnellen Auslieferung nicht geholfen, wenn die Qualität darunter leidet. Bei der kontinuierlichen Testmethode sind automatisierte Tests in die Pipeline für die Softwareauslieferung eingebunden. In der Pipeline werden dann in jeder Phase Tests durchgeführt, um die in der jeweiligen Phase erstellten Artefakte zu prüfen. Bei Unit-Tests und statischen Codeanalysen werden in der Komponentenphase der Pipeline Komponenten geprüft. Subsysteme werden im Rahmen von Funktions-, Leistungs- und Sicherheitstests in der Subsystemphase kontrolliert, während Systeme durch Integrations-, Leistungs- und Sicherheitstests in der Systemphase überprüft werden. Die abschließenden Smoke-Tests dienen der Prüfung des Produkts in der Produktionsphase.

Abbildung: Code-Review

Automatisierte Tests, die in die Pipeline eingebunden werden

Eine monolithische Produktarchitektur, d. h., der bekannte "Big Ball of Mud", kann einen Rattenschwanz an Tests nach sich ziehen. Daher empfehlen wir Microservices, damit unabhängig voneinander bereitstellbare Artefakte die Pipeline durchlaufen können, ohne dass du zur Zertifizierung eine in hohem Maße integrierte Umgebung benötigst. Mit solchen eigenständig bereitstellbaren Artefakten müssen sich schnellere Teams auch nicht mehr von langsameren Teams ausbremsen lassen.

Mehrwert durch Continuous Delivery


Die Software Delivery-Pipeline ist ein eigenes Produkt, das sich vorrangig an Unternehmen richtet. Abgesehen davon ist es nicht ratsam, sie für umsatzstarke Produkte zu verwenden. Continuous Delivery steigert den Mehrwert auf drei Arten. Die Methode verbessert die Geschwindigkeit, Produktivität und Nachhaltigkeit von Softwareentwicklerteams.

Abbildung: Rakete

Velocity

Unter Velocity verstehen wir eine verantwortbare und keine halsbrecherische Geschwindigkeit. Das Ziel von Pipelines ist das Ausliefern qualitativ hochwertiger Produkte an Kunden. Wenn es Teams an Disziplin mangelt, kann mit Pipelines fehlerhafter Code in die Produktion einfließen – und zwar noch schneller! Automatisierte Pipelines für die Softwareauslieferung helfen Unternehmen, besser auf Marktänderungen zu reagieren.

Abbildung: Code-Pipeline

Produktivität

Die Produktivität steigt, wenn du mühsame Tasks statt von einem Menschen über eine Pipeline durchführen lässt, wie etwa das Einreichen von Anfragen für einzelne Änderungen, die in die Produktion gehen sollen. So können sich Scrum-Teams ganz auf die Entwicklung von Produkten konzentrieren, die die Welt begeistern, und vergeuden ihre Energie nicht mit logistischen Herausforderungen. Und Teammitglieder sind womöglich zufriedener, arbeiten motivierter und wollen länger im Team bleiben.

Abbildung: Entscheidung

Nachhaltigkeit

Nachhaltigkeit ist nicht nur für Technologiefirmen, sondern alle Unternehmen von zentraler Bedeutung. Die Aussage "Software frisst die Welt" ist überholt – Software hat die Welt längst gefressen. Überall, ganz gleich, ob im Gesundheitswesen, in Finanzinstituten, im Einzelhandel oder in anderen Branchen, will sich jeder mithilfe von Technologie von der Konkurrenz abgrenzen und einen Vorteil verschaffen. Durch Automatisierung kannst du die Zahl manueller Tasks, die fehleranfällig und wiederkehrend sind, reduzieren oder sie ganz umgehen, damit sich dein Unternehmen optimal positionieren kann, um Innovationen besser und schneller voranzutreiben und so die kundenseitigen Anforderungen zu erfüllen.

Für wen ist Continuous Delivery geeignet – und wann?


Wann ist der richtige Zeitpunkt zum Einführen von Continuous Delivery? Am besten bereits gestern.
Teams benötigen einen einzigen priorisierten Backlog, der folgende Anforderungen erfüllt:

  1. Continuous Delivery steht im Mittelpunkt statt im Hintergrund.
  2. In den Akzeptanzkriterien von User Storys werden Ansätze zur automatischen Softwareauslieferung ausdrücklich der manuellen Bereitstellung vorgezogen.
  3. Die Definition von "Erledigt" für Sprints verhindert, dass Teams Sprints mit manueller Produktauslieferung abschließen.

Continuous Delivery ist die richtige Vorgehensweise. Manchmal ist für die Transformation allerdings Starthilfe von Experten notwendig. Bei richtiger Gestaltung amortisieren sich Continuous Delivery-Pipelines schnell.

Wer ist zuständig?

Manche Unternehmen lassen unerfahrene Mitarbeiter ihre Continuous-Delivery-Pipelines planen und implementieren und stellen zu spät fest, wie viel dabei zu beachten ist. Wenn Mitarbeiter einer niedrigen Hierarchieebene für diese Aufgabe verantwortlich sind, sendet dies falsche Signale an die Teams – es legt nahe, dass Continuous Delivery dem Unternehmen nicht wichtig ist. Daher empfehlen wir dringend, die Aufgabe einem erfahrenen Architekten zu übertragen, der sich mit der Technologie und dem Geschäft gleichermaßen gut auskennt.

Über Continuous Delivery hinaus


Unabhängig von deinem aktuellen Stand solltest du den Weg zu Continuous Everything (Integration, Tests, Auslieferung, Deployment, Analysen) auf keinen Fall als abzuhakende Checkliste oder als Ziel betrachten, sondern als einen fortlaufenden Optimierungsprozess.

Wenn in einem Unternehmen Continuous-Delivery-Pipelines eingerichtet werden, kommt früher oder später jeder mit dem Thema in Berührung. Führungskräfte, die Entwicklungsabteilung, das Produktmanagement, die Governance-, Risk-, Compliance-, Informationssicherheits- und Operations-Teams, die Rechtsabteilung und alle anderen. Pipelines ersetzen Silos und überwinden Grenzen. Auf die ein oder anderen Weise sind wir alle Teil dieser Transformation und Continuous Everyone ist der neue Standard!

Einstieg in CI/CD

Zur Durchführung von CI/CD kannst du Tools verwenden, die Entwicklungs-, Deployment- und Testphasen automatisieren. Manche Tools helfen dir bei der Integration, andere bei der Entwicklung und dem Deployment und andere beim Testen.

Atlassian bietet eine Open DevOps-Lösung, die End-to-End-DevOps-Prozesse einschließlich CI/CD bereitstellt. Teams können auf zahlreiche CI/CD-Tools zugreifen, wie zum Beispiel Bitbucket Pipelines, einen in Bitbucket integrierten CI/CD-Service, der auf Basis einer Konfigurationsdatei in deinem Repository die Automatisierung von Builds, Tests und sogar Deployments deines Codes ermöglicht. Open DevOps kann außerdem in andere CI/CD-Tools integriert werden, zum Beispiel Harness, GitLab, JFrog, Codefresh und CircleCI.

Hier erfährst du mehr zu unseren Open DevOps-Integrationen. Schaue dir auch unsere DevOps-CI/CD-Tutorials an.

Abbildung: Continuous Delivery