Unterschiede zwischen Continuous Integration, Delivery und Deployment
Lerne die Unterschiede zwischen diesen Continuous-Verfahren kennen.
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.
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.
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.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
DevOps-Community
Blog lesen
