Schließen

Grundlagen einer Continuous Delivery-Pipeline

Erfahre, wie automatisierte Builds, Tests und Deployments zu einem einzigen Release-Workflow verbunden werden.

Was ist eine Continuous Delivery-Pipeline?

How does a pipeline relate to continuous delivery (CD)? As the name suggests, a continuous delivery pipeline is an implementation of the continuous paradigm, where automated builds, tests and deployments are orchestrated as one release workflow. Put more plainly, a CD pipeline is a set of steps your code changes will go through to make their way to production.

A CD pipeline delivers, as per business needs, quality products frequently and predictably from test to staging to production in an automated fashion.

For starters, let’s focus on the three concepts: quality, frequently, and predictably.

We emphasize on quality to underscore that it’s not traded off for speed. Business doesn’t want us to build a pipeline that can shoot faulty code to production at high speed. We will go through the principles of “Shift Left” and “DevSecOps”, and discuss how we can move quality and security upstream in the SDLC (software development life cycle). This will put to rest any concerns regarding continuous delivery pipelines posing risk to businesses.

Frequently indicates that pipelines execute at any time to release features, since they are programmed to trigger with commits to the codebase. Once the pipeline MVP (minimum viable product) is in place, it can execute as many times as it needs to with periodic maintenance cost. This automated approach scales without burning out the team. This also allows teams to make small incremental improvements to their products without the fear of a major catastrophe in production.

Cliche as it may sound, the nation of “to err is human” still holds true. Teams brace for impact during manual releases since those processes are brittle. Predictably implies that releases are deterministic in nature when done via continuous delivery pipelines. Since pipelines are programmable infrastructure, teams can expect the desired behavior every time. Accidents can happen, of course, since no software is bug-free. However, pipelines are exponentially better than manual error-prone release processes, since unlike humans, pipelines don’t falter under aggressive deadlines.  

Pipelines verfügen über Software-Gates, an denen automatisch entschieden wird, ob versionierte Artefakte passieren dürfen oder abgelehnt werden. Wird das Release-Protokoll nicht beachtet, bleiben die Software-Gates geschlossen und die Pipeline bricht ab. Es werden Warnungen generiert und Benachrichtigungen an eine Verteilerliste mit Teammitgliedern gesendet, die möglicherweise für den Fehler in der Pipeline verantwortlich sind.

Genauso funktioniert eine CD-Pipeline: Bei jeder erfolgreichen Ausführung der Pipeline geht ein Commit oder ein kleiner, inkrementeller Batch von Commits in Produktion. Später liefern die Teams Features und schließlich Produkte auf sichere, nachvollziehbare Weise aus.

Continuous delivery pipeline articles

[CONTINUED]

Phasen einer Continuous Delivery-Pipeline

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 Pipelinemuster, in dem mehrere Pipelines auf komplexen Wegen schließlich zur Produktion führen.

Außerdem beeinflusst die Produktarchitektur die verschiedenen Phasen der Pipeline und die darin produzierten Artefakte. In der Regel umfasst Continuous Delivery die folgenden 4 Phasen:

Even if you foresee more than four phases or less than four in your organization, the concepts outlined below still apply.

Es ist ein weit verbreiteter Irrtum, dass diese Phasen immer physisch in der Pipeline erkennbar sind. Dies muss nicht unbedingt der Fall sein. Es handelt sich um logische Phasen, die Umgebungsmeilensteinen wie Test, Staging und Produktion zugeordnet werden können. So könnten beispielsweise Komponenten und Subsysteme erstellt, getestet und in einer Testumgebung bereitgestellt werden. Subsysteme oder Systeme könnten zusammengestellt, getestet und in einer Staging-Umgebung bereitgestellt werden oder sie könnten im Rahmen der Produktionsphase an die Produktion übermittelt werden.

Die durch Fehler verursachten Kosten sind in der Testphase gering, beim Staging mittelhoch und in der Produktion hoch. "Shift Left" bedeutet, dass Überprüfungen auf einen früheren Punkt der Pipeline verschoben werden. Das Gate zwischen Test und Staging ist heute mit deutlich mehr Abwehrtechniken ausgerüstet, sodass Staging nicht mehr wie ein Tatort aussehen muss.

Früher kam InfoSec am Ende des Softwareentwicklungszyklus (Software Development Lifecycle, SDLC) zum Zuge, um Releases abzulehnen, die die Cybersicherheit des Unternehmens bedrohen könnten. Trotz der hehren Absichten führte die zu Frustration und Verzögerungen. Bei "DevSecOps" besteht das Ziel darin, Sicherheitsmaßnahmen schon ab der Designphase in das Produkt zu integrieren, statt erst das (möglicherweise nicht sichere) fertige Produkt zur Evaluierung zu schicken.

Sehen wir uns einmal genauer an, wie "Shift Left" und "DevSecOps" im Continuous Delivery-Workflow berücksichtigt werden können. In den nächsten Abschnitten behandeln wir jede Phase im Detail.

CD Component phase

The pipeline first builds components - the smallest distributable and testable units of the product. For example, a library built by the pipeline can be termed a component. A component can be certified, among other things, by code reviews, unit tests, and static code analyzers.

Codeüberprüfungen sind für Teams wichtig, um ein gemeinsames Verständnis der Features, Tests und Infrastrukturkomponenten zu entwickeln, die für die Markteinführung des Produkts benötigt werden. Vier Augen sehen mehr als zwei. Im Laufe der Jahre fällt uns fehlerhafter Code vielleicht nicht mehr auf, weil wir nicht mehr glauben, dass es sich um echte Fehler handelt. Ein neuer Blickwinkel kann uns zwingen, diese Schwachstellen noch einmal zu betrachten und sie bei Bedarf zu überarbeiten.

Unit-Tests sind in den meisten Fällen die ersten für den Code durchgeführten Softwaretests. Die Datenbank und das Netzwerk bleiben davon unberührt. Die Codeabdeckung zeigt, welcher prozentuale Anteil des Codes Unit-Tests durchlaufen hat. Sie lässt sich auf verschiedene Arten messen, beispielsweise in Form von Zeilenabdeckung, Klassenabdeckung oder Methodenabdeckung.

Eine hohe Codeabdeckung ist zwar für das Refactoring von Vorteil, festgelegte Ziele für eine hohe Abdeckung sind jedoch kontraproduktiv. Man würde es nicht vermuten, aber manche Teams mit einer hohen Codeabdeckung verzeichnen mehr Produktionsausfälle als Teams mit geringerer Codeabdeckung. Zudem lassen sich die Abdeckungszahlen leicht manipulieren. Unter akutem Druck, besonders bei Leistungsprüfungen, nutzen Entwickler unter Umständen unlautere Methoden zur Steigerung der Codeabdeckung. Näher möchte ich hier nicht darauf eingehen.

Static code analysis detects problems in code without executing it. This is an inexpensive way to detect issues. Like unit tests, these tests run on source code and have low run-time. Static analyzers detect potential memory leaks, along with code quality indicators like cyclomatic complexity and code duplication. During this phase, SAST (static analysis security testing) is a proven way to discover security vulnerabilities.

Definiere die Metriken, die deine Software-Gates steuern und den Übergang des Codes von der Komponentenphase in die Subsystemphase beeinflussen.

CD-Subsystemphase

Lose miteinander verbundene Komponenten bilden zusammen ein Subsystem, d. h. die kleinste bereitstellbare und ausführbare Einheit. Ein Server ist beispielsweise ein Subsystem. Auch ein in einem Container ausgeführter Mikroservice ist ein Beispiel für ein Subsystem. Im Gegensatz zu Komponenten können Subsysteme im Hinblick auf Use Cases bei Kunden überprüft werden.

Eine Node.js-UI und ein Java-API-Layer sind ebenso Subsysteme wie eine Datenbank. Manche IT-Abteilungen verwalten ein RDBMS (relationales Datenbankmanagementsystem) manuell, obwohl es inzwischen neue Tools gibt, die das Änderungsmanagement für Datenbanken automatisieren und sich für Continuous Delivery bei Datenbanken bewährt haben. CD-Pipelines mit NoSQL-Datenbanken sind einfacher zu implementieren als RDBMS.

Subsystems can be deployed and certified by functional, performance, and security tests. Let’s study how each of these test types validate the product.

Funktionstests betreffen alle Use Cases bei Kunden im Zusammenhang mit Aspekten wie Internationalisierung (I18N), Lokalisierung (L10N), Datenqualität, Zugänglichkeit und Negativszenarien. Mit diesen Tests wird sichergestellt, dass dein Produkt den Kundenanforderungen entspricht, die Inklusion berücksichtigt und für den Zielmarkt geeignet ist.

Lege zusammen mit den Produktinhabern die Benchmarks für die Leistung fest. Integriere die Leistungstests in die Pipeline, wobei die Benchmarks darüber entscheiden, ob die Pipeline fortgesetzt oder abgebrochen wird. Einem verbreiteten Mythos zufolge müssen Leistungstests nicht in die Continuous Delivery-Pipeline integriert werden. Dies widerspricht jedoch dem Prinzip der Kontinuität.

Verschiedene große Unternehmen sind in letzter Zeit Opfer von Hackerangriffen geworden und die Anzahl der Bedrohungen für die Cybersicherheit ist höher denn je. Wir müssen daher aufrüsten und dafür sorgen, dass unsere Produkte keinerlei Sicherheitsschwachstellen enthalten – sei es in unserem eigenen Code oder in Bibliotheken von Drittanbietern, die wir in unseren Code importieren. Tatsächlich wurden bei OSS (Open-Source-Software) bereits größere Sicherheitsverletzungen entdeckt. Wir müssen daher Tools und Techniken einsetzen, die diese Fehler erkennen und einen Abbruch der Pipeline erzwingen. DAST (Dynamic Analysis Security Testing) ist eine bewährte Methode zur Erkennung von Sicherheitsschwachstellen.

Die Abbildung unten verdeutlicht den im Zusammenhang mit der Komponenten- und Subsystemphase beschriebenen Workflow. Führe die voneinander unabhängigen Schritte parallel aus, um die Ausführungszeit der Pipeline insgesamt zu verkürzen und schneller Feedback zu erhalten.

A) Certifying components and/or subsystems in the test environment

CD-Systemphase

Once subsystems meet functional, performance, and security expectations, the pipeline could be taught to assemble a system from loosely coupled subsystems in cases where the entire system has to be released as a whole. What that means is that the fastest team can go at the speed of the slowest team. Reminds me of the old saying, “A chain is only as strong as its weakest link”.

We recommend against this composition anti-pattern where subsystems are composed into a system to be released as a whole. This anti-pattern ties all the subsystems at their hips for success. If you invest in independently deployable artifacts, you will be able to avoid this anti-pattern.

Where systems need to be validated as a whole, they can be certified by integration, performance, and security tests. Unlike subsystem phase, do not use mocks or stubs during testing in this phase. Also, focus on testing interfaces and network more than anything else.

In der Abbildung unten ist der Workflow aus der Systemphase dargestellt, falls du deine Subsysteme per Komposition zusammenfügen musst. Auch wenn du deine Subsysteme direkt in Produktion gehen lassen kannst, hilft dir die Abbildung beim Einrichten von Software-Gates, die für den Übergang des Codes von dieser Phase in die nächste benötigt werden.

The pipeline can automatically file change requests (CR) to leave an audit trail. Most organizations use this workflow for standard changes, which means, planned releases. This workflow should also be used for emergency changes, or unplanned releases, although some teams tend to cut corners. Note how the change request (CR) is closed automatically by the CD pipeline when errors force it to abort. This prevents CRs from being abandoned in the middle of the pipeline workflow.

Die Abbildung unten verdeutlicht den im Zusammenhang mit der CD-Systemphase beschriebenen Workflow. Ein Hinweis dazu: Bei einigen Schritten kann manuelles Eingreifen erforderlich sein. Diese manuellen Schritte können als Bestandteil manueller Gates in der Pipeline ausgeführt werden. Wenn wir die gesamte Pipeline visualisieren, ähnelt sie stark der Darstellung der Wertstromanalyse für das Produkt-Release.

B) Zertifizierung von Subsystemen und/oder Systemen in der Staging-Umgebung

Nach der Zertifizierung des zusammengestellten Systems wird die Zusammenstellung unverändert an die Produktion übermittelt.

CD-Produktionsphase

Unabhängig davon, ob die Subsysteme eigenständig bereitgestellt werden können oder zu einem System zusammengestellt werden müssen, werden die versionierten Artefakte im Zuge dieser finalen Phase in der Produktionsumgebung bereitgestellt.

ZDD (Zero Downtime Deployment, Deployment ohne Ausfallzeit) ist unverzichtbar, damit es für die Kunden nicht zu Ausfällen kommt, und sollte von den Tests über das Staging bis hin zur Produktion gegeben sein. Eine beliebte ZDD-Technik ist Blue Green Deployment. Dabei werden die neuen Bestandteile für eine kleine Schnittmenge von Kunden ("Green") bereitgestellt, während der große Rest ("Blue") mit den alten Bestandteilen davon unberührt bleibt. Wenn es hart auf hart kommt, kannst du einfach alles auf "Blue" zurücksetzen, sodass nur bei sehr wenigen Kunden (wenn überhaupt) Störungen auftreten. Sieht bei "Green" alles gut aus, kannst du nach und nach alles von "Blue" auf "Green" umstellen.

Bei manchen Unternehmen ist ein manuelles Gate (oder auch zwei) vor dem Deployment der Pipeline in der Produktionsumgebung vorgeschrieben. Es gibt Szenarien, in denen manuelle Gates gerechtfertigt sind, weil das Unternehmen beispielsweise zunächst eine bestimmte geografische oder demografische Schnittmenge der Kunden als Zielgruppe nutzen und dort Daten erfassen möchte, bevor das Release für alle Kunden stattfindet.

In einigen Unternehmen werden manuelle Gates jedoch meiner Meinung nach missbraucht. Sie schreiben vor, dass die Teams in einem CAB-Meeting (Change Approval Board) eine manuelle Genehmigung einholen müssen. Dies ist in vielen Fällen auf eine Fehlinterpretation der Funktionstrennung oder Separation of Concerns zurückzuführen. Es erfolgt eine Übergabe von einer Abteilung an eine andere, um die Genehmigung zum Fortfahren zu erhalten. Ich habe auch schon erlebt, dass es den Genehmigern aus dem CAB an technischen Kenntnissen über die in Produktion gehenden Änderungen mangelte, wodurch der manuelle Genehmigungsprozess langsam und schwerfällig wurde.

This is a good segway to call out the difference between continuous delivery and continuous deployment. Continuous delivery allows manual gates whereas continuous deployment doesn’t. While both are referred to as CD, continuous deployment requires more discipline and rigor since there is no human intervention in the pipeline.

Es besteht ein Unterschied zwischen dem Verschieben und dem Aktivieren der Bestandteile. Du solltest Smoke-Tests in der Produktionsumgebung durchführen. Dabei handelt es sich um eine Untermenge der Integrations-, Leistungs- und Sicherheitstestsuites. Nach bestandenem Smoke-Test kannst du die Bestandteile aktivieren, woraufhin das Produkt für die Kunden verfügbar wird.

The following diagram illustrates the steps carried out by the team in this final phase of continuous delivery.

C) Certifying subsystems and/or system in the production environment

Continuous Delivery als neuer Standard

Wenn du mit Continuous Delivery oder Continuous Deployment Erfolg haben willst, sind auch Continuous Integration und Continuous Testing unverzichtbar. Eine solide Grundlage bringt an allen drei Fronten Vorteile (hochwertig, häufig und planbar).

A continuous delivery pipeline helps your ideas become products through a series of sustainable experiments. If you discover your idea isn’t as good as you thought it was, you can quickly turn around with a better idea. Additionally, pipelines reduce the MTTR (mean time to resolve) production issues, thus reducing downtime for your customers. With continuous delivery, you end up with productive teams and satisfied customers, and who doesn’t want that?

Learn more in our Continuous Delivery tutorial.

Juni Mukherjee
Juni Mukherjee

Juni is a thought citizen in the DevSecOps space and has made deep investments in the field of Continuous Delivery. She has helped organizations build Continuous Delivery Pipelines, and would love to solve the problems that plague our industry today. She has authored a couple of books.