Africa Studio - stock.adobe.com
Zwischen Continuous Delivery und Continuous Deployment wählen
Kontinuierliche Auslieferung und Bereitstellung verschlanken die letzten Schritte beim Produkt-Rollout. Erfahren Sie hier, wie Sie sich zwischen beiden Methoden entscheiden.
Die meisten Unternehmen für Softwareentwicklung verlassen sich heute auf einen Pipeline-Prozess, um Programme zu erstellen und prüfen. Sie setzen auf kurze Feedbackschleifen, die schnell offenlegen, wenn der Build defekt ist und welche Änderung ihn beschädigt hat. Für den letzten Schritt der Produktbereitstellung haben Kompilierungsprüfungen und Komponententests in einer Welt interpretierter Sprachen, Webanwendungen und APIs weniger Wert.
Stattdessen beschleunigen Continuous Delivery und Continuous Deployment Bereitstellungen bei geringerem Risiko und verlagern die Qualität nach rechts in den Zuständigkeitsbereich des Betriebspersonals.
Aber welcher Bereitstellungspfad ist der richtige für Sie? Ein genauerer Blick auf Continuous Delivery (kontinuierliche Auslieferung) im Vergleich zu Continuous Deployment (kontinuierliche Bereitstellung) wird Ihnen dabei helfen, herauszufinden, was für Ihr Unternehmen derzeit am besten geeignet ist.
Der Weg von Continuous Integration zu Continuous Delivery und Continuous Deployment
Eine CI/CD-Pipeline beginnt mit Continuous Integration (kontinuierliche Integration, CI), einem Prozess, der Code sammelt und integriert. Was Integration genau heißt, kann je nach Team und Organisation variieren; ursprünglich bedeutete es, laufend Code zu kompilieren, aber heute gehören dazu auch begleitende Sicherheitsprüfungen, Scanner für häufig auftretende Fehler beim Kompilieren und Komponententests. Wenn Tests fehlschlagen, weiß der CI-Server genau, aus welchem Commit (und von welchem Autor) die Änderung stammen und benachrichtigt Verantwortliche, damit sie den Fehler beheben.
Sobald der Code die Tests bestanden hat, wird er automatisch bereitgestellt (Continuous Deployment) oder eine Person wird damit beauftragt, damit sie die abschließenden Prüfungen durchführt und dann eine Bereitstellung auslöst (Continuous Delivery).
Continuous Delivery und Continuous Deployment komprimieren den Bereitstellungsprozess und stellen sicher, dass Prüfungen konsistent sind, um das Risiko zu reduzieren. Diese automatisierten Prozesse konzentrieren sich auf Überwachungs- und Rollback-Funktionen. Sie erfordern auch einen umfassenden Satz automatisierter Tools oder Prozesse, um kleine Teilkomponenten zu veröffentlichen, die ein geringeres Risiko bergen
Continuous Delivery in der Praxis
Sobald der Code in die Versionsverwaltung eingeht, wird er getestet, repariert und ausgerollt. Zu den Schritten auf diesem Weg gehören Unit-Tests, das Erstellen eines virtuellen Servers und das anschließende Ausführen automatisierter High-Level-Prüfungen für den Server. Wenn an irgendeinem Punkt die Tests fehlschlagen, wird der Build pausiert und das System benachrichtigt den Entwickler per E-Mail. Besteht der Build alle Tests, geht der Code an ein letztes Stage-Gate, bevor er bereitgestellt wird.
Bei der kontinuierlichen Auslieferung ist der Idealzustand, dass das Veröffentlichen von Features und Softwareteilen nur noch einen einzigen Klick erfordert. Dieser letzte Klick löst die eigentliche Bereitstellung aus. In Abbildung 1 generiert der Abschluss des automatisierten Abnahmetests Feedback bis hin zu den menschlichen Softwaretestern. In diesem Schritt sendet das System eine E-Mail an einen Tester, Product Owner oder Kundendienstmitarbeiter, um die Umgebung zu erkunden und zu überprüfen. Geben sie den Release frei, rollt der Code in die Produktion.
Der letzte Test ist nicht der einzige Grund für diesen Schritt. Ein Product Owner, der die Benutzeroberfläche gestaltet, möchte möglicherweise eine Reihe von Änderungen gleichzeitig freigeben. Das Unternehmen kann alle Änderungen in einem Sprint für einen abschließenden Regressions-Burndown-Check einführen oder vielleicht an einem bestimmten Tag und zu einer bestimmten Uhrzeit, um das Geschäftsrisiko oder die Zahl der betroffenen Nutzer zu verringern. In einigen Fällen können architektonische Einschränkungen die Einführung von Mikrofunktionen oder Mikro-Commits verhindern.
Hat ein Team eine Pipeline vom Commit zum fertigen Produkt etabliert und ist in der Lage, entkoppelt von dieser auch mehrmals täglich Code bereitzustellen, nennt man das Continuous Delivery. Das Ersetzen dieser letzten menschlichen Kontrolle durch Automatisierung ist der Hauptunterschied zum anderen CD-Modell – der kontinuierlichen Bereitstellung.
Cl/CD in der Cloud
Eine einzige Testumgebung ist nicht mehr zeitgemäß. Die heutigen Continuous-Integration-Tools können für jede Version der Software eine andere Testumgebung erstellen. Diese Tools können komplett in der Cloud leben und Benutzer interagieren mit ihnen über einen Browser. In einer solchen Umgebung kann der Wechsel von Continuous Delivery zu Continuous Deployment das Verschieben eines Workflow-Schritts bedeuten – nur die Tester oder Mitarbeiter können diese Änderung sehen, die dann in der Produktion getestet und an alle weitergegeben oder bei Bedarf zurückgestellt wird.
Fortschrittliche Organisationen, die CI/CD-Tools in der Cloud verwenden, sind möglicherweise besser dran, mit kontinuierlicher Bereitstellung zu beginnen und nur im Fall von Qualitätsproblemen auf kontinuierliche Bereitstellung zurückzufallen.
Kontinuierliche Bereitstellung in der Praxis
Bei einer Continuous-Deployment-Umgebung wechseln die Änderungen nach Absolvieren der Tests zur Staging-Ebene. Dies birgt natürlich Risiken, gegen die es einige bewährte Maßnahmen gibt:
- Konfigurations-Flags. Wenn eine Änderung eingeführt wird, betrifft sie nur eine kleine Untergruppe von Benutzern, beispielsweise bestimmte Mitarbeiter oder sogar nur die Tester. Die Funktionen können mit einem einfachen Bit-Flip in einer Datenbank oder einer Textdatei auf eine größere Benutzerkategorie erweitert werden.
- Bereitstellung isolierter Komponenten. Der Online-Marktplatz Etsy beispielsweise ist früh auf kontinuierlicher Bereitstellung umgezoen und setzte auf die Programmiersprache PHP. Jede Webseite war eine .php-Datei, ähnlich den früheren HTML-Seiten. Eine typische Seite enthält möglicherweise etwas JavaScript und ein Stylesheet, aber sofern zu diesem Code keine Codebibliothek gehört, können die Bereitstellungen getrennt stattfinden. Dies gilt auch für Software, die das Frontend (Grafik) von der Mittelschicht (APIs) trennt.
- Automatisierte Verträge. API- und Code-Spezifikationen definieren, was die Software tun soll und ob sie auf einem bescheidenen, grundlegenden Niveau noch funktioniert.
- Versionierte Interaktionen. Wichtige Versions-Updates einer API können Änderungen scheitern lassen. Um dies zu beheben, lassen Sie den Code eine bestimmte Version der API aufrufen. Geringfügige Versionsänderungen ändern nicht den oben genannten Vertrag, die Schnittstelle oder die erwarteten Ergebnisse.
Damit die kontinuierliche Bereitstellung funktioniert, benötigt Ihr Unternehmen sowohl eine Architektur als auch eine Infrastruktur, die solche Praktiken unterstützt, einige der oben genannten Mechanismen zur Selbstunterstützung und qualifiziertes Personal, um schnell und qualitativ hochwertigen Code zu erstellen.
Treffen Sie die Wahl: Continuous Delivery versus Continuous Deployment
Die meisten Unternehmen werden feststellen, dass es relativ einfach ist, einen Continuous-Delivery-Prozess einzuführen: Setzen Sie einen Build auf, führen Sie Komponententests durch, und wenn die Komponententests erfolgreich sind, verschieben Sie den Build auf einen Entwicklungs- oder Testserver.
Der Wechsel von Continuous Delivery zu Continuous Deployment ist für viele Unternehmen schwieriger. Organisationen mit herkömmlichen isolierten Entwicklungs-, Test- und Staging-Servern können mit einer gewissen Instabilität in der Entwicklung fertig werden, dies erfordert jedoch menschliche Eingriffe in mehreren Phasen (Push-to-Test, dann bei bestandenen Tests, dann ein weiterer Push-to-Test an die menschlichen Tester und dann Push-to-Produktion). Dies verlangsamt den gesamten Prozess, aber geschieht in der Hoffnung, dass es die Qualität verbessert.
Legacy-Softwareteams, die zur kontinuierlichen Bereitstellung übergehen möchten, müssen sich auf ernsthafte Hindernisse einstellen. In vielen Fällen werden Programme beispielsweise in einer großen Datei bereitgestellt und der Prozess verursacht Ausfälle von mehr als 30 Sekunden. Oft sind Bereitstellungen nicht isoliert, APIs nicht versioniert oder dem System fehlen automatisierte Verträge. Diese Teams sind möglicherweise besser dran, mit Continuous Delivery zu beginnen und Architektur nach und nach anzupassen, bis eine kontinuierliche Bereitstellung umsetzbar ist.
