Continuous Delivery (CD)
Continuous Delivery (CD, Kontinuierliche Auslieferung) ist ein Ansatz für die Softwarebereitstellung, bei dem Entwicklungsteams Code in kurzen, kontinuierlichen Zyklen erstellen und testen, normalerweise mit einem hohen Automatisierungsgrad. Dieser Prozess ermöglicht es Entwicklern, Software schnell zu erstellen, zu testen und bereitzustellen, indem mehr inkrementelle Updates empfohlen werden, statt einen großen Teil der Zeit für das vollständige Überholen eines bestimmten Produkts aufzuwenden.
Die kontinuierliche Bereitstellung ist ein beliebter Ansatz für die Softwarebereitstellung, insbesondere für DevOps-Teams. Die kontinuierliche Bereitstellung zielt darauf ab, die Feedbackschleifen so kurz wie möglich zu halten, um die Softwarequalität zu verbessern. Der Code wird regelmäßig an Benutzerakzeptanztests (User Acceptance Testing, UAT) oder eine Staging-Umgebung gesendet. Code kann auf alle Aspekte der Funktionalität hin getestet werden, wodurch unerwartete Leistungsprobleme in der Produktion verringert werden sollen.
Besteht eine Komponente alle Tests, kann sie in die Produktion übergeben werden. Bei Continuous Delivery führen Entwickler die Tests frühzeitig durch – ein Konzept, das manchmal als Shift Left Testing bezeichnet wird. Auf diese Weise können Entwickler an Korrekturen arbeiten, bevor sie zu anderen Aspekten der Entwicklung übergehen.
Die Pipeline für Continuous Delivery
Es gibt keine Standard-Pipeline für die Continuous Delivery. Typischerweise legen sie jedoch den Fokus auf Themen wie automatisierte Builds, Tests und Staging-Bereitstellungen in einem kontinuierlichen Prozess. Der erste Schritt in der Pipeline besteht darin, dass Entwickler die kleinsten verteilbaren Codeeinheiten schreiben und festschreiben.
Dieser Schritt kann als ein Element der kontinuierlichen Lieferung betrachtet werden. Der Code wird durch Überprüfungen, Komponententests und statische Analysen getestet. Tests mit kleinen Codemengen können effizienter sein als End-to-End-Tests. Zu diesem Zeitpunkt sollte der Code ausführbar sein. Tests sollten auf Subsystemebene durchgeführt werden, einschließlich Funktions-, Leistungs- und Sicherheitstests.
Die Tests sollen sicherstellen, dass der entwickelte Code den Qualitätsstandards eines Endbenutzers und den Spezifikationen des Projekts entspricht. Als nächstes erfordern integrierte Subsysteme UI- und Netzwerktests – und möglicherweise noch weitere Funktions-, Leistungs- und Sicherheitsüberprüfungen. In dieser Phase der Pipeline können Entwickler die Anwendungskomponenten getrennt halten, um Microservices zu bilden, oder als ein komplettes System zusammen integriert werden. Schließlich sollte die Software bereit sein, in der Produktionsumgebung bereitgestellt zu werden. Davor sollten Entwickler jedoch den Code manuell überprüft, bevor er für die Bereitstellung akzeptiert wird.
Blue/Green Deployment ist eine gängige Bereitstellungsmethode für Continuous Delivery, bei der zwei Umgebungen identisch konfiguriert sind. Die eine Umgebung bedient Endbenutzer, während in der anderen Entwickler neuen Code bereitstellen und testen, zum Beispiel mit einen Belastungstest, um die Leistung bei hoher Kapazität zu messen. Wenn der freigegebene Code als bereit erachtet wird, tauschen die Umgebungen Traffic-Quellen und der neue Code steht den Benutzern zur Verfügung.
Wenn nach dem Wechsel Probleme auftreten, kann der Datenverkehr zur vorherigen Umgebung zurückgeleitet werden, während das Softwareteam das Problem behebt. Die durchgeführten Tests sollten nach Möglichkeit automatisiert sein. Daneben gibt es noch andere Strategien: Beispielsweise kann Continuous Integration (CI, kontinuierliche Integration) auch mit Continuous Delivery kombiniert werden, so dass Code, der von mehreren Entwicklern an mehreren Standorten verarbeitet wird, in einem einzigen Repository enthalten ist. Dann sind auch kontinuierliche Tests erforderlich, um mit den Arbeitsabläufen Schritt zu halten.
Die Vorteile von Continuous Delivery
Kontinuierliche Bereitstellung vereinfacht die Softwarebereitstellung im Vergleich zu Methoden wie dem Wasserfallmodell, da ein Entwicklerteam nicht so viel Zeit für die Vorbereitung einer Codebasis für die Veröffentlichung aufwenden muss und auch nicht mehrere einzelne Änderungen für eine große Version gebündelt werden. Stattdessen aktualisiert und veröffentlicht das Team den Code in kleinen Schritten. Kleine Releases decken Fehler in neuem Code schneller auf.
Wenn beispielsweise ein Entwicklerteam Code in der Produktionsumgebung bereitstellt und einen Fehler findet, kann es den fehlerhaften Code auf eines der letzten inkrementellen Updates eingrenzen. Sie können das Problem beheben, den Code testen, erneut bereitstellen und neues Feedback erhalten. Darüber hinaus ermöglicht Continuous Delivery schnellere Anwendungsiterationen, da viele Entwickler zu unterschiedlichen Zeiten zusammenarbeiten und Code erstellen können, ohne andere Projekte zu beeinträchtigen.
Wenn ein iterativer Prozess aufgrund der zunehmenden Komplexität des Projekts unhandlich wird, bietet die kontinuierliche Bereitstellung Entwicklern die Möglichkeit, wieder kleinere, häufigere Releases zu erstellen, die zuverlässiger, vorhersehbarer und leichter zu verwalten sind.
Continuous Delivery und DevOps
Continuous Delivery passt ideal zu einem DevOps-Ansatz. DevOps hat das Ziel, Administratoren und Entwickler in einem Team zur Zusammenarbeit zu bringen, häufig mit einem starken Fokus auf Automatisierung. Die kontinuierliche Bereitstellung erleichtert diesen Prozess, indem sie das fortlaufende Erstellen, Testen und Bereitstellen von Software ermöglicht. Die Ziele von DevOps und Continuous Delivery sind darauf ausgerichtet, einen kontinuierlichen Workflow zu ermöglichen. Einer der wichtigsten Schwerpunkte bei der kontinuierlichen Bereitstellung ist das schnelle Erstellen, Testen und Freigeben von Software; dasselbe gilt für DevOps. Große und kleine DevOps-Unternehmen nutzen Continuous Delivery, um schnellere und qualitativ hochwertigere Softwareentwicklung, Freigabeprozesse und Code-Commits zu erreichen.
Continuous Delivery und Continuous Integration
Continuous Delivery ist eine Erweiterung des Konzepts der kontinuierlichen Integration. CI ist eine Softwareentwicklungspraxis, bei der Entwickler häufige, isolierte Änderungen sofort testen und dann zu einer größeren Codebasis hinzufügen. Wenn CI den Build- und den ersten Codetestteil des Entwicklungszyklus für jede Version behandelt, konzentriert sich die kontinuierliche Bereitstellung darauf, was passiert, nachdem festgeschriebene Änderungen erstellt wurden.
Mit CI können alle Codekopien aller Entwickler regelmäßig in einer Codebasis zusammengeführt werden. Isolierte Änderungen können schnell getestet und in Unit- und Integrationstests eingebaut werden. Durch die kontinuierliche Integration kann ein Entwicklungsteam spezifisches Feedback zu Änderungen oder Ergänzungen der Codebasis erhalten. Wenn ein Fehler auftritt, sollten die Codetests in CI ihn aufdecken, lange bevor der Code veröffentlicht wird.
CI und kontinuierliche Lieferung werden häufig als CI/CD kombiniert, da kontinuierliche Lieferung als Fortsetzung von CI fungiert. Jedes Commit, das die automatisierten Tests besteht, gilt als Kandidat für die Freigabe. Durch CI und kontinuierliche Bereitstellung kann ein Unternehmen automatisierte Test- und Staging-Prozesse nutzen, anhand derer Entwickler entscheiden, wann und wie oft sie Code in der Produktion bereitstellen. Es ist jedoch wichtig zu beachten, dass das CD in CI CD auch für Continuous Deployment – Kontinuierliche Bereitstellung – stehen kann.
Continuous Delivery und Continuous Deployment
Kontinuierliche Auslieferung und kontinuierliche Bereitstellung sind ähnliche Konzepte, die häufig miteinander verwechselt werden. Beide teilen das Akronym CD und können, um die Verwirrung perfekt zu machen, mit kontinuierlicher Integration zusammen genutzt werden.
Der größte und bemerkenswerteste Unterschied ist der Aufbau der Bereitstellungspipeline. Bei Continuous Delivery durchläuft der Code automatisch mehrere Schritte, um ihn für die Bereitstellung in der Produktion vorzubereiten. Er wird jedoch nicht automatisch live geschaltet.
Die Codeänderungen müssen zuerst manuell genehmigt werden, und es gibt manuelle Tests und Qualitätssicherungsmaßnahmen (QS). Bei Continuous Deployment kann Code jedoch automatisch getestet, überprüft und in einer Produktionsumgebung freigegeben werden, wo er automatisch an die Anforderungen der Benutzer angepasst und auf Probleme hin überwacht wird, die ein Rollback erforderlich machen würden. Continuous Delivery umfasst normalerweise auch einen produktionsähnlichen Bereitstellungsbereich. Dadurch kann es häufig zu einer Zeitverzögerung zwischen einer Testversion und der Freigabe von neuem Code für die Produktion kommen.
Hier kann Continuous Deployment seine Vorteile ausspielen. Für die kontinuierliche Bereitstellung ist kein Staging-Bereich für Codeänderungen erforderlich. Stattdessen werden automatisierte Tests früh in den Entwicklungsprozess integriert und in allen Phasen der Veröffentlichung fortgesetzt.
Beide Prozesse sind angewiesen auf Tools zur flexiblen Bereitstellung von Infrastruktur und zur Überwachung von Anwendungen, um Probleme zu erfassen, die nicht in der Feedbackschleife enthalten sind. Continuous Integration, Deployment und Delivery werden zusammenfassend als Continuous Software Development (kontinuierliche Softwareentwicklung)
Werkzeuge für Continuous Delivery
Für jede Phase der kontinuierlichen Auslieferung stehen eine Vielzahl von Open Source und proprietären Tools sowie Tools für Continuous Integration und Delivery zur Verfügung.
Im Allgemeinen verwenden Softwareteams, die eine kontinuierliche Bereitstellung praktizieren, ein Versionskontrollsystem, um Code zu verwalten. eine automatisierte Build-Engine; Einheits-, Funktions- und Integrationstestsysteme; Leistungstester für normale Last- und Stresstests; Konfigurationsmanagement-Tools; und ein Artefakt-Repository.
Teams verwenden auch auf Container, um eine konsistente Softwarebereitstellung in verschiedenen Umgebungen zu gewährleisten – von der Entwicklung über den Test bis hin zur Produktion und integrierten Entwicklungsumgebungen.
Das verringert Komplikationen beim Erstellen und Testen. Die genannten Tools lassen sich alle in ein kontinuierliches Pipeline-Tool wie Jenkins oder CircleCI integrieren. Viele Public-Cloud-Anbieter haben auch integrierte Tools für die kontinuierliche Bereitstellung im Servicekatalog. Entwickler und IT-Mitarbeiter können diese Tools von der Codeentwicklung über die Bereitstellung und Produktion bis hin zur Überwachung und Skalierung verwenden.
