In dem ersten Artikel unserer Reihe CI/CD haben wir über das Thema Continuous Integration gesprochen. Der heutige Blogpost betrachtet die zweite Hälfte des Acronyms CI/CD, Continuous Delivery. Continuous Delivery setzt dort an, wo Continuous Integration endet. CD nimmt den Software Build aus dem CI Prozess und geht den nächsten Schritt in eine „Acceptance Environment“. Dort wird weiter getestet, bevor der Code dann endgültig für die Produktion (Release Version) freigegeben wird.
Hier noch einmal ein kurzer Rückblick. CI übernimmt die initiale Planung, die Entwicklung des Codes und das Testing. Hierdurch ist es möglich, in kurzen Zyklen neue Software bzw. Funktionalitäten in immer neuen Schleifen zu entwickeln. Die Entwickler übertragen den Code in ein Version-Control-System, in dem Prozesse zum automatischen kompilieren und testen ablaufen. Nach Abschluss der Tests wird der Code an den CD Prozess übergeben. Hier endet dann der Ablauf aus Entwicklung, Delivery und Maintenance von Software.
Was ist Continuous Delivery?
Das Ergebnis von CI ist eine neue stabilisierte Version einer Applikation mit neuen Funktionalitäten und Bugfixes. Im Rahmen des CD Prozesses wird der neue Code von der Entwicklungsumgebung an eine oder mehrere neue Testumgebungen übergeben. Hier wird der Code weiter geprüft. Das Entwicklungs- und Operations-Team (DevOps) entscheidet im Weiteren mit anderen Stakeholdern, ob und wann die neue Software-Version für die Produktion freigegeben wird. Ist die Freigabe erfolgt, übernimmt ein automatisierter Prozess das Deployment.
Ebenso wie die CI Phase besteht auch die CD Phase aus vier Schritten: Release, Deploy, Operate und Monitor. Dieser Prozess wiederholt sich unter Umständen mehrfach und endet jeweils mit dem Deployment in unterschiedliche Umgebungen mit verschiedenen Tests, bevor die Software letztendlich für die Produktion freigegeben wird.
Auch wenn manche Prozesse direkt zu einer Auslieferung in die Produktionsumgebung führen, in den meisten Fällen erfolgt vorher eine Übergabe in eine Staging oder Acceptance Umgebung. In dieser Acceptance Umgebung werden weitere automatisierte Tests durchgeführt, die Software detailliert überwacht und die verschiedenen Stakeholder prüfen die neuen Features. Das nachfolgende Diagramm zeigt noch einmal die CD-Seite des CI/CD Prozesses.
- Die Entwicklung übergibt den Software Build an den CD-Prozess.
- Operations übergibt die Applikation entweder in eine Produktions- oder Acceptance-Umgebung.
- Stakeholder nutzen und prüfen die Applikation.
- Automatische Systeme überwachen die Verfügbarkeit, Performance und Funktion.
- Das Feedback der Nutzer und die Ergebnisse der Tests fließen zurück in die CI Planungsphase.
Der Unterschied zwischen Acceptance und Produktion
Produktion ist die aktive Live-Version einer API, Web Applikation oder Webseite. Jeder Fehler in der Software und jede Schwäche in der Infrastruktur haben direkte Auswirkungen auf die Nutzer des Produkts. Obwohl einzelne Prozesse direkt in die Produktion ausliefern, die meisten gehen durch eine Reihe von Überprüfungen bevor sie endgültig ausgeliefert werden.
Die Acceptance Umgebung erlaubt es den Stakeholdern sich die neueste Software-Version anzuschauen, zu testen und zu prüfen, bis sie tatsächlich in Produktion geht. Bevor das Operations-Team eine endgültige Freigabe erteilt, müssen eine Reihe von Aufgaben in der Acceptance Umgebung abgeschlossen sein.
- Usability Testing: Das User Experience Team arbeitet mit echten Nutzern. Mit den Tests wird sichergestellt, dass die Applikation einfach zu bedienen ist und die User Aufgaben korrekt abschließen können.
- Load Testing: Was passiert, wenn mehrere Nutzer (bestenfalls Tausende) die Applikation gleichzeitig nutzen? Halten Software und Hardware der Belastung stand?
- Soak Testing: Wie verhält sich das System bei dauerhafter Belastung?
- Stakeholder Evaluation: Die Stakeholder geben ihr Feedback und bei einem positiven Ergebnis die Freigabe für das Deployment in Produktion. Zu den Stakeholdern gehören oftmals Vertreter aus dem Management und Mitarbeitern aus verschiedenen Abteilungen, wie Qualitätssicherung, User Experience oder anderer Abteilungen, die direkt oder indirekt mit dem Produkt zu tun haben.
Warum Continuous Delivery nutzen?
Continuous Integration und Continuous Delivery sind Werkzeuge, die es der Software-Entwicklung ermöglichen, Software schneller und mit weniger Fehlern an die Nutzer auszuliefern. Weiter Vorteile von Continuous Delivery sind:
- Geringes Risiko: Bei kontinuierlichen und kleinen Änderungen kommt es zu weniger Fehlern. Kommt es doch zu einem Fehler, ist dieser auf Grund des kurzen Prozesszyklus schneller zu bereinigen oder rückgängig zu machen.
- Schnellerer Feedback Loop: Die direkte Kommunikation mit Operations und Stakeholdern erlaubt es der Entwicklung, unmittelbar auf deren Feedback zu reagieren.
- Schnellere Reaktion auf veränderte Anforderungen: Auf verändertes Nutzerverhalten, wie einem veränderten Produktfokus oder der Verwendung anderer Geräte für den Zugang zur Plattform, kann deutlich schneller reagiert werden.
- Reduzierung von Engpässen: Mit kleineren und häufigeren Updates werden personelle und Kapazitätsengpässe vermieden, die immer wieder bei großen Updates auftreten. Ein Beispiel hierfür ist die Prüfung eines Updates durch die Qualitätssicherung. Gibt es in einem Update nur 12 kleine Änderungen, können diese innerhalb kurzer Zeit ohne Bindung umfangreicher Ressourcen geprüft werden. Im Vergleich hierzu bindet ein Update mit tausenden Änderungen eine große Anzahl Mitarbeiter und ist mit einem massiven Zeitaufwand verbunden.
Was ist der Unterschied zwischen Continuous Delivery und Continuous Deployment?
Beide, Continuous Delivery und Continuous Deployment, folgen im Entwicklungsprozess der Phase CI. Der Unterschied zwischen beiden Prozessen ist der Automatisierungsgrad. Beim Continuous Deployment ist der Prozess komplett automatisiert. Hat das Software-Release den automatischen Testprozess erfolgreich durchlaufen, erfolgt das automatische Deployment in die Produktion.
Im Vergleich hierzu liegt beim Continuous Delivery die Entscheidung über das Deployment der Software bei Entwicklung und Operations. Kommt es zu einer Freigabe, wird der automatische Prozess des Deployments gestartet.
Fokus auf Automatisierung
Ebenso wie bei CI liegt der Fokus bei CD auf einer umfangreichen Automatisierung von Prozessen. Automatisierte Prozesse importieren die Software, aktualisieren Infrastrukturen oder Daten. Auch Tests, wie Smoke-Test, Load-Test und Soak-Test werden automatisch angestoßen. Mit Continuous Delivery ist die Auslieferung neuer Software immer nur ein paar Klicks entfernt. In der Produktion wird automatisiert mittels eines kontinuierliches Monitoring die Erreichbarkeit, die Performance und die Funktion von Seiten sowie Prozessen überwacht.
Uptrends und Deine Acceptance Umgebung
Deine Acceptance Umgebung stellt einen Spiegel Deiner Live-Umgebung dar. Das Uptrends Monitoring ist hierbei ein fester Bestandteil Deiner CD Automatisierungs- und Testprozesse. Indem Du Deine Acceptance-Umgebung aus dem Internet zugreifbar machst (mit oder ohne Authentifizierung), bist Du in der Lage mit dem Uptrends Monitoring Netzwerk, bestehend aus über 200 Standorten, darauf zuzugreifen und umfangreiche Tests durchzuführen. Du kannst Deine APIs und Webseiten auf Erreichbarkeit, Performance und Funktion testen. Besteht kein Zugriff aus dem Internet, solltest Du darüber nachdenken einen Uptrends Private Checkpoint innerhalb Deiner Infrastruktur zu nutzen. Damit kannst Du auch hinter Deiner Firewall auf die kompletten Möglichkeiten des Uptrends Monitorings zurückgreifen. Erfahre hierüber mehr in unserem nächsten Artikel.
Nächster Artikel: Uptrends und Dein CI/CD Prozess
