Unterschiede zwischen Continuous Integration, Delivery und Deployment

Lerne die Unterschiede zwischen diesen Continuous-Verfahren kennen.

Porträt von Sten Pittet
Sten Pittet

Gastautor


CI und CD sind zwei Akronyme, die häufig in modernen Entwicklungsverfahren und DevOps verwendet werden. CI steht für Continuous Integration, eine grundlegende Best Practice von DevOps, bei der Entwickler Codeänderungen regelmäßig in einem zentralen Repository mergen, in dem automatisierte Builds und Tests ausgeführt werden. CD kann jedoch entweder Continuous Delivery oder Continuous Deployment bedeuten.

Welche Unterschiede bestehen zwischen Continuous Integration, Continuous Delivery und Continuous Deployment (CI/CD)?


Continuous Integration

Entwickler, die mit Continuous Integration arbeiten, mergen ihre Änderungen so oft wie möglich zurück in den Haupt-Branch. Zur Validierung der vom Entwickler vorgenommenen Änderungen wird ein Build erstellt, der dann automatische Tests durchläuft. Auf diese Weise lassen sich die Integrationsprobleme vermeiden, die möglicherweise auftreten, wenn die Entwickler mit dem Mergen der Änderungen in den Release-Branch bis zum Release-Datum warten.

Bei der Continuous Integration wird großer Wert auf die Testautomatisierung gelegt, um die Anwendung auf Fehlerfreiheit zu überprüfen, wenn neue Commits in den Haupt-Branch integriert werden.

Continuous Delivery

Continuous Delivery ist eine Erweiterung der Continuous Integration, da alle Codeänderungen nach der Build-Phase automatisch in einer Test- und/oder Produktionsumgebung implementiert werden.

Dies bedeutet, dass du zusätzlich zu automatisierten Tests über einen automatisierten Release-Prozess verfügst und deine Anwendung jederzeit mit einem Klick auf eine Schaltfläche bereitstellen kannst.

Theoretisch kannst du mit Continuous Delivery entscheiden, ob du täglich, wöchentlich, vierzehntägig oder in sonstigen deinen Geschäftsanforderungen entsprechenden Intervallen veröffentlichst. Wenn du jedoch wirklich die Vorteile der Continuous Delivery nutzen möchtest, solltest du die Anwendung so früh wie möglich für die Produktion bereitstellen, damit kleine Batches veröffentlicht werden können, an denen eventuelle Probleme leicht zu beheben sind.

Lösung anzeigen

Hochwertige Software entwickeln und ausführen mit Open DevOps

Zugehöriges Material

Was ist die DevOps-Pipeline?

Continuous Deployment

Continuous Deployment geht noch einen Schritt weiter als Continuous Delivery. Bei dieser Methode wird jede Änderung, die sämtliche Stationen der Produktionspipeline durchlaufen hat, für die Kunden freigegeben. Dieser Prozess erfolgt vollautomatisch. Nur wenn ein Test fehlschlägt, wird eine neue Änderung nicht in der Produktion bereitgestellt.

Continuous Deployment ist eine hervorragende Möglichkeit, die Feedbackschleife mit deinen Kunden zu beschleunigen und den Druck auf das Team zu mildern, da es keinen "Release-Tag" mehr gibt. Entwickler können sich auf die Entwicklung von Software konzentrieren und sehen, wie ihr Werk Minuten nach der Fertigstellung live geht.

Wie stehen die Verfahren miteinander in Beziehung?


Einfach formuliert ist Continuous Integration ein Bestandteil von Continuous Delivery und Continuous Deployment. Continuous Deployment entspricht Continuous Delivery – abgesehen von den automatisch erfolgenden Releases.

Unterschiede zwischen Continuous Integration, Continuous Delivery und Continuous Deployment

Welche Vorteile bieten die einzelnen Verfahren?


What are the benefits of each practice?

Wir haben den Unterschied zwischen Continuous Integration, Continuous Delivery und Continuous Deployments erläutert, aber wir haben noch nicht die Gründe untersucht, warum du diese Methoden einführen solltest. Die Implementierung neuer Verfahren ist natürlich mit Kosten verbunden, diese werden jedoch von den Vorteilen weitgehend wettgemacht.

Continuous Integration

Anforderungen (Kosten)

  • Dein Team muss für jede neue Funktion, Verbesserung oder Fehlerbehebung automatisierte Tests schreiben.
  • Du benötigst einen Continuous Integration-Server zum Überwachen des Haupt-Repositorys und zum Ausführen der automatischen Tests für alle neu übermittelten Commits.
  • Die Entwickler müssen ihre Änderungen so oft wie möglich (mindestens einmal am Tag) mergen.

Vorteile

  • Es werden weniger Fehler in die Produktion übergeben, da Regressionen durch die automatisierten Tests früh entdeckt werden.
  • Das Erstellen des Release-Build ist einfach, da alle Integrationsprobleme frühzeitig gelöst wurden.
  • Weniger Kontextwechsel, da die Entwickler benachrichtigt werden, sobald ihnen beim Build ein Fehler unterläuft, und diesen Fehler beheben können, bevor sie sich einer anderen Aufgabe zuwenden.
  • Die Testkosten werden drastisch reduziert – dein CI-Server kann in Sekundenschnelle Hunderte von Tests durchführen.
  • Dein QS-Team verbringt weniger Zeit mit Tests und kann sich auf deutliche Verbesserungen der Qualitätskultur konzentrieren.

Continuous Delivery

Anforderungen (Kosten)

  • Du brauchst eine starke Grundlage für die Continuous Integration, und deine Testsuite muss deine Codebasis ausreichend abdecken.
  • Deployments müssen automatisiert werden. Der Trigger ist immer noch manuell, aber sobald ein Deployment gestartet ist, sollte kein menschliches Eingreifen erforderlich sein.
  • Dein Team wird höchstwahrscheinlich Feature Flags verwenden müssen, damit unvollständige Funktionen die Kunden in der Produktion nicht beeinträchtigen.

Vorteile

  • Software-Deployments sind weniger komplex. Dein Team muss sich nicht mehr tagelang auf einen Release vorbereiten.
  • Releases können öfter stattfinden, was die Feedbackschleife mit den Kunden beschleunigt.
  • Es lastet viel weniger Druck auf Entscheidungen für kleine Änderungen, was dazu ermutigt, schneller zu iterieren.

Continuous Deployment

Anforderungen (Kosten)

  • Deine Testkultur muss optimal sein. Die Qualität deiner Testsuite entscheidet über die Qualität deiner Releases.
  • Der Dokumentationsprozess muss mit dem schnelleren Deployment Schritt halten können.
  • Feature Flags werden zu einem festen Bestandteil des Release-Prozesses wichtiger Änderungen, um die Abstimmung mit anderen Abteilungen (Support, Marketing, PR etc.) sicherzustellen.

Vorteile

  • Du kannst schneller entwickeln, da die Entwicklung für Releases nicht unterbrochen wird. Deployment-Pipelines werden bei jeder Änderung automatisch ausgelöst.
  • Releases sind weniger riskant und eventuelle Probleme leichter zu beheben, da du Änderungen in kleinen Batches bereitstellst.
  • Kunden erleben fortlaufende Verbesserungen und tägliche statt monatliche oder quartalsweise Qualitätssteigerungen.

Zu den traditionellen Kosten im Zusammenhang mit der Continuous Integration gehört die Installation und Wartung eines CI-Servers. Du kannst jedoch die Kosten für die Einführung dieser Verfahren erheblich reduzieren, indem du einen Cloud-Service wie Bitbucket Pipelines verwendest, der jedem Bitbucket-Repository Automatisierung hinzufügt. Indem du einfach eine Konfigurationsdatei im Stammverzeichnis deines Repository hinzufügst, kannst du eine Continuous-Deployment-Pipeline erstellen, die für jede neue Änderung ausgeführt wird, die in den Haupt-Branch verschoben wird.

Eine Pipeline für Continuous Deployment in Bitbucket

Von Continuous Integration zu Continuous Deployment


Wenn du gerade erst mit einem neuen Projekt ohne Benutzer beginnst, ist es möglicherweise am einfachsten, jeden Commit in der Produktion bereitzustellen. Du kannst sogar damit beginnen, deine Deployments zu automatisieren und deine Alpha-Version in einer Produktionsumgebung ohne Kunden zu veröffentlichen. Dann kannst du deine Testkultur verbessern und sicherstellen, dass bei der Entwicklung deiner Anwendung mehr Code abgedeckt ist. Wenn du dann bereit bist, Benutzer einzuführen, verfügst du über einen großartigen Continuous-Deployment-Prozess, bei dem alle neuen Änderungen getestet werden, bevor sie automatisch in der Produktion veröffentlicht werden.

Wenn du jedoch bereits eine bestehende Anwendung für Kunden hast, solltest du das Ganze langsamer angehen und mit Continuous Integration und Continuous Delivery beginnen. Beginne mit der automatischen Ausführung grundlegender Unit-Tests. Mit komplexen End-to-End-Tests musst du dich vorerst noch nicht auseinandersetzen. Stattdessen solltest du versuchen, deine Deployments so schnell wie möglich zu automatisieren und eine Phase zu erreichen, in der Deployments in deinen Staging-Umgebungen automatisch durchgeführt werden. Denn durch automatische Deployments kannst du deine Energie für die Verbesserung deiner Tests aufwenden, anstatt ständig deine Arbeit zu unterbrechen, um einen Release zu koordinieren.

Sobald du in der Lage bist, täglich Software zu veröffentlichen, kannst du dich mit Continuous Deployment befassen. Vergewissere dich aber zunächst, ob das übrige Unternehmen ebenfalls dafür bereit ist: Dokumentation, Support, Marketing usw. Diese Funktionen müssen sich an die neuen Release-Intervalle anpassen. Es ist wichtig, dass sie alle wesentlichen Änderungen berücksichtigen, die sich auf die Kunden auswirken können.

Lies unsere Leitfäden


Read our guides

Es gibt einige Leitfäden, die dir den Einstieg in diese Verfahren erleichtern.

Sten Pittet
Sten Pittet

Ich bin seit 10 Jahren in der Softwarebranche tätig und hatte schon verschiedene Positionen inne, unter anderem in der Entwicklung und im Produktmanagement. Nachdem ich in den letzten 5 Jahren bei Atlassian an Entwickler-Tools gearbeitet habe, schreibe ich jetzt über das Erstellen von Software. In meiner Freizeit feile ich zusammen mit meinem Kleinkind an meinen Kompetenzen als Vater.


Diesen Artikel teilen

Lesenswert

Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.

Abbildung: DevOps

DevOps-Community

Abbildung: Karte

Kostenlos loslegen

Melde dich für unseren DevOps-Newsletter an

Thank you for signing up