Continuous Integration (CI), Continuous Deployment (CD), Continuous Delivery (CD) – was heißt das eigentlich genau? || DevOps Series – Episode 3

In diesem Artikel erklären wir die Unterschiede zwischen Continuous Integration (CI), Continuous Deployment (CD) und Continuous Delivery (CD). Wir zeigen dir unter anderem, was die einzelnen Bestandteile der jeweiligen Pipeline sind und die wichtigisten Tools.

In der letzten Folge haben wir die wichtigsten Tipps, Links, Bücher, Fragen und Beispielquiz für die Professional Scrum Master 1 (PSM1) Prüfung von scrum.org vorgestellt für dich, dass du diese wichtige Prüfung erfolgreich meistern kannst.

Schau also unbedingt hier vorbei falls du darüber mehr lernen willst.

Die drei unterschiedlichen DevOps Pipelines

Zu aller erst möchten wir hier kurz klären, dass Continuous Integration (CI), Continuous Deployment (CD) und Continuous Delivery (CD) nicht die einzigen Bestandteile von DevOps sind, auch wenn es sicherlich die bekanntesten sind. DevOps an sich hat nämlich, wie Agile auch, z.B. sehr viel mit Kultur, kontinuierlicher Verbesserung und Feedback zu tun.

Wenn du also noch mehr über DevOps und was es alles bedeutet lernen willst schau direkt hier vorbei, abonnier unseren Newsletter, Podcast und YouTube Channel und freu dich über wöchentlich neue Artikel.

Um die Gründe bzw. den Bedarf für die Existenz dieser Pipelines zu verstehen schauen wir uns kurz den Lebenszyklus von Softwareentwicklung (Software Development Life Cycle) an.

Die Entwicklung von Software (wie die meisten anderen Entwicklungsprozesse auch) folgt einem gewissen Ablauf. Als erstes muss man natürlich wissen, welche neuen Features die Kunden bzw. Stakeholder benötigen und damit einen Mehrwert schaffen. Das kann z.B. das Ergebnis eines Sprint Reviews mit den Nutzern sein. Hier sollte man versuchen direkt möglichst viel über die Anforderungen (Requirements) der Nutzer herauszufinden, da dies viele Diskussionen während der Implementierung vereinfacht.

Wenn das alles bekannt ist, kann man das neue Feature einplanen und das erste Design besprechen. Z.B. im Sprint Planning. Dann folgt auch schon das entwickeln bzw. programmieren und testen des neuen Features (hier habe ich schon etwas vorgegriffen, da in einem klassischen Wasserfallvorgehen das testen erst ganz am Schluss kommen würde, was viele Nachteile hat).

Als letzter Schritt kommt natürlich das veröffentlichen (release) des neuen Features.

Der Softwareentwicklungszyklus

Folgt man diesem Zyklus strikt (wie z.B. in einem Wasserfall-Modell), so arbeiten die Entwickler diesen Zyklus einfach ab und sind während dieser Zeit sowohl von den Nutzern, als auch von anderen Entwicklern getrennt (Silos), was nahezu immer zu massiven Integrationsproblemen (Merge Hell) am Schluss führt.

Um, unter anderem, dieses Problem zu lösen wird in der Agile Softwareentwicklung bzw. DevOps dieser Prozess möglichst häufig und früh durchlaufen. Also mit möglichst kleinen inkrementellen Änderungen anstatt riesigen Big-Bang Releases nach jahrelanger Entwicklung.

Will man nun aber regelmäßig stabilen Code ausliefern bedeutet das auch, dass es einfach sein muss Code auszuliefern (also möglichst komplett automatisiert) und dass man schnell Feedback bekommt, ob nach der Integration noch alles so funktioniert, wie es soll.

Und genau da kommen die bereits angesprochenen DevOps Pipelines ins Spiel. Hier gibt es drei verschiedene Möglichkeiten, die alle einen Schritt weitergehen, als die vorangegangen Möglichkeit und aufeinander aufbauen.

In den nächsten Abschnitten erklären wir die einzelnen Schritte und Tools der jeweiligen Pipeline genau.

Continuous Integration (CI)

Continuous Integration ist eine Methode der agilen Softwareentwicklung und kommt ursprünglich aus dem Extreme Programming (XP). Der Fokus liegt hier darauf, dass jede Änderung, die im Version Control System (VCS; z.B. Git) landet automatisch gebaut und getestet wird.

„Continuous Integration (CI) is a software development practice where members of a team integrate their work frequently; […]. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible“. – Martin Fowler [Betonung durch uns hinzugefügt]

Beispiel einer Continuous Integration Pipeline

Um eine Continuous Integration Pipeline aufzubauen benötigt man:

• Ein Versionsverwaltungssystem:
  • Dieses speichert den gesamten Quellcode aller beteiligten Teams und stellt die Single Source of Truth dar.
  • Beispiele hierfür sind GitHub oder GitLab
• Automatisierte Builds und Tests
  • Diese sind nötig, da es nicht ausreichend ist, dass der Code auf dem PC des Entwicklers funktioniert, sondern auch in anderen Umgebungen (Environments). Idealerweise wird jeder einzelne Commit der im Versionsverwaltungssystem landet gebaut und getested wird durch einen unabhängigen Continuous Integration Server.
  • Beispiele hierfür sind Jenkins und Selenium
• Feedback
  • Die Entwickler brauchen schnelles und klares Feedback zu ihren Commits. Immer wenn ein Entwickler einen Bug in den neuesten Build einbringt, muss er dazu schnell Feedback (z.B. per Mail oder ChatOps (z.B. via Slack)) bekommen, um das Problem so schnell wie möglich lösen zu können
• Eine vereinbarte, gemeinsame Arbeitsweise
  • Grundlage von all dem ist, dass alle Entwickler in den Teams sich daran halten ihre inkrementellen Änderungen regelmäßig zu commiten, anstatt zu warten bis diese vollständig entwickelt sind.
  • Absolute Priorität gilt hier für das beheben von Problemen im Build (in DevOps wird das als „Swarming“ (ausschwärmen) bezeichnet)

Continuous Integration löst aber vor allem die Probleme während der Entwicklungsphase. Aber ,wie wir in unserem Bild zum Softwareentwicklungszyklus gesehen haben, gehört zu Softwareentwicklung noch mehr dazu als nur Feature zu entwickeln und die Änderungen zu integrieren.

Continuous Delivery (CD)

Es gehört nämlich auch dazu, dass regelmäßig auf produktionsähnlichen Umgebungen (production-like Environments) getestet wird, um Probleme in diesen realistischen Umgebungen, die durchaus sehr von den lokalen Maschinen abweichen können, schnell zu finden. Und natürlich gehört auch der gesamte Release-Prozess, also das tatsächliche Deployment beim Kunden oder in die Produktionsumgebung, dazu.

Im Gegensatz zu einer Continuous Integration Pipeline gehört dies bei der Continuous Delivery Pipeline dazu.

Beispiel einer Continuous Delivery Pipeline

„Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.“ – Martin Fowler [Betonung durch uns hinzugefügt]

Um Continuous Delivery zu erreichen müssen mehrere Bedingungen erfüllt sein:

• Die Software kann in jeder Phase des Zyklus deployed werden.
• Das Team setzt die Priorität darauf die Software „deployable“ (einsetzbar) zu halten und dann erst kommt die Entwicklung neuer Features
• Jeder bekommt schnell und automatisiert Feedback zum Zustand des Produkts/Systems
• Es ist möglich mit einem Knopfdruck jede Version der Software auf egal welche Umgebung on-demand auszurollen.

Um dieses ambitionierte Ziel zu erreichen benötigt man eine sehr enge Zusammenarbeit zwischen allen, die an dem Produkt beteiligt sind (Kernidee der DevOps-Kultur) und eine umfangreiche Automatisierung aller Teile/Schritte des Delivery-Prozesses. Dies ist meistens in Form der gerade beschriebenen Continuous Delivery Pipeline.

Gründe für den manuellen Schritt zum Deployment können zum Beispiel sein, dass man noch die Zustimmung einer bestimmten Person benötigt, um das neue Feature ausrollen zu können.

Continuous Deployment (CD)

Continuous Deployment geht im Vergleich zu Continuous Delivery nun noch einen kleinen Schritt weiter, indem nun auch das Deployment des Releases in die Produktionsumgebung komplett automatisiert abläuft.

Beispiel einer Continuous Delivery Pipeline

Voraussetzung hierfür ist natürlich eine funktionierende Continuous Delivery Pipeline.

Tools

Wichtig um sich eine der drei vorgestellten Pipelines aufbauen zu können, ist natürlich die Kenntnis der richtigen Tools, für die entsprechende Aufgabe.

Damit dieser Artikel nicht viel zu lang wird geben wir hier aber nur eine Übersicht einer der bekanntesten Tools.

• Ein Versionierungssytem wie z.B. Git, um den Quellcode zu speichern
• Ein Continuous Integration Tool, wie z.B. Jenkins, um automatisierte Builds zu erzeugen.
• Test-Frameworks wie z.B. xUnit, Selenium, etc um verschiedeneste Tests auszuführen
• Ein Repository für alle Build-Artekfate, wie z.B. Artifactory.
• Ein Konfigurationsmangement Tool, wie z.B. Ansible
• Ein Dashboard, um den Status und Fortschritt sichtbar zu machen, wie z.B. Prometheus oder Grafana
• Ein Tool, um automatisiert Benachrichtigungen an die entsprechenden Entwickler zu senden, wie z.B. Slack.

Das ist allerdings noch nicht alles, da wir ja ein Tool benötigen, dass all diese Tools zusammenbringt. Nur so schaffen wir es das Ziel einer CI/CD Pipeline, nämlich automatisierte Software Delivery, zu erreichen.

Fazit

Um in der aktuellen Zeit konkurrenzfähig zu bleiben, indem man schnell, für den Kunden wertvolle Software entwickelt, ist ein CI/CD-Pipeline unumgänglich. Diese ermöglicht es Fehler früh zu finden und damit schnell lösen zu können und viele Integrationsprobleme durch späte Integration erst gar nicht auftreten zu lassen. Welche der drei Methoden man wählt ist natürlich abhängig vom Bedarf des Unternehmens. Eine CI-Pipeline aufzubauen ist aber immer ein guter erster Schritt und auch Voraussetzung für die weiteren „Ausbaustufen“, wie einer Continuous Delivery Pipeline.

Wir, und die meisten unserer Kunden, bevorzugen eine Continuous Delivery Lösung, da es auf Grund der Marketing- und Bussinessstrategie des Unternehmens es in der Regel sinnvoll ist, das Ausrollen neuer Features zu einem ganz bestimmten Zeitpunkt durchführen zu können.

Egal für welche dieser drei Lösungen man sich entscheidet, ist neben einer guten Kenntnis der Tools, ein hoher Grad an Automatisierung der einzelnen Schritte der Entwicklung und konstantes Feedback extrem wichtig. Der aber mit Abstand wichtigste Faktor ist eine starke und gut funktionierende, enge Zusammenarbeit zwischen allen beteiligten Teams und Rollen. Dies ist absolut essenziell, da es sich bei der Entwicklung von Software nunmal um ein hoch komplexes Problem handelt, bei dem alle in die gleiche Richtung ziehen müssen, sonst ist das Produkt zum scheitern verurteilt.

Continuous Delivery bietet ein Framework, um all das im Rahmen des DevOps–Gedanken und der DevOps–Kultur, nämlich keine Silos zu haben und geteilte Verantwortlichkeit (das bedeutet aber nicht, dass am Ende niemand verantwortlich ist), zu ermöglichen.

Du willst noch mehr wissen und hast noch Fragen oder bist anderer Meinung?

Schreib uns das auch unbedingt in die Kommentare und wir werden dir gerne und ausführlich antworten!

Da das jetzt alles wieder sehr viel Input auf einmal war, haben wir eine einfache Übersicht über alles was zum Scrum Rahmenwerk gehört, für dich in einem kostenlosen Poster dargestellt. Du findest es hier:

Damit du all die gelernten Begriffe auch schnell nachschauen kannst, haben wir dir zusätzlich einen kostenlosen Glossar auf Deutsch mit +230 Begriffen zu DevOps, Agile und Lean mit den entsprechenden englischen Fachbegriffen (macht das Googeln meist einfacher, da es noch sehr wenige vollständige deutsche Blogs zu diesen Themen gibt) erstellt.

Und auch der ist komplett kostenlos. Du findest den Glossar hier:

Ausblick

In der nächsten Folge erklären wir dir, warum Scrum und DevOps ein perfektes Match sind und wie das Unternehmen und alle Angestellten davon profitieren können.

Falls du das nicht verpassen willst und ein noch besserer Scrum Master/Agile Coach/Product Owner/Entwickler oder Leader werden willst, melde dich jetzt für unseren kostenlosen Newsletter an:

Unser Podcast

Und falls du unsere Experteninterviews und alle anderen Podcast-Folgen als erster bequem unterwegs hören willst, abonnier einfach unseren Podcast mit folgendem RSS-Feed:

Podcast RSS-Feed

Unser YouTube-Channel

Du stehst auf bewegtes Bild und zusätzliche Grafiken und Visualisierungen? Dann ab auf unseren YouTube-Channel „Agile Coach Academy“.

Abonniere den Channel und verpasse kein Video oder Experteninterview mehr.

Wie immer freuen wir uns auch wenn du diesen Artikel mit deinen Freunden, Kollegen und Bekannten teilst und uns dein ehrliches Feedback in den Kommentaren schickst.

Wir freuen uns auf dich in der nächsten Folge.

Deine Agile Coach Academy Gründer Ben und Alex