CI und CD sind Akronyme für moderne Entwicklungspraktiken. CI ist unkompliziert und steht für Kontinuierliche Integration (continuous integration), eine Praxis, die sich darauf konzentriert, die Vorbereitung eines Releases zu erleichtern. Aber CD kann entweder Kontinuierliche Lieferung (continuous delivery) oder Kontinuierliche Bereitstellung (continuous deployment) bedeuten, und obwohl diese beiden Praktiken viel gemeinsam haben, haben sie auch einen signifikanten Unterschied, der kritische Folgen für ein Unternehmen haben kann. Wir werden in diesem Artikel sehen, was diese drei Praktiken bedeuten und was erforderlich ist, um sie zu nutzen. Außerdem gibt es eine schnelle Kosten-Nutzen-Analyse.

Kontinuierliche Integration

Entwickler, die eine kontinuierliche Integration praktizieren, führen ihre Änderungen so oft wie möglich in den Hauptzweig zurück. Die Änderungen des Entwicklers validiert man, indem ein Team einen Build erstellt und automatisierte Tests gegen den Build durchführt. Auf diese Weise vermeidet man die Integrationshölle, die normalerweise passiert, wenn Leute auf den Release-Tag warten, um ihre Änderungen in den Release-Zweig einzubinden. Die kontinuierliche Integration legt großen Wert auf die Testautomatisierung, um sicherzustellen, dass die Anwendung nicht unterbricht, wenn man neue Anforderungen in den Hauptzweig integriert. Einer der traditionellen Kosten im Zusammenhang mit der kontinuierlichen Integration ist die Installation und Wartung eines CI-Servers. Man kann die Kosten für die Einführung dieser Verfahren erheblich senken, indem man einen Cloud-Service verwendet.

Kosten

• Ein Team muss automatisierte Tests für jede neue Funktion, Verbesserung oder Fehlerbehebung schreiben.
• Man benötigt einen Continuous Integration Server, der das Haupt-Repository überwachen und die Tests automatisch für jeden neue Anforderungen ausführen kann.
• Entwickler müssen ihre Änderungen so oft wie möglich zusammenführen, mindestens einmal täglich.

Nutzen

• Es werden weniger Fehler an die Produktion weitergeleitet, da Regressionen durch die automatisierten Tests frühzeitig erfasst werden.
• Die Erstellung des Releases ist einfach – frühzeitige Lösung aller Integrationsprobleme.
• Weniger Kontextwechsel, da Entwickler benachrichtigt werden, sobald sie den Build abbrechen. Sie können daran arbeiten, ihn zu reparieren, bevor sie zu einer anderen Aufgabe wechseln.
• Drastische Reduktion der Testkosten – ein CI-Server kann Hunderte von Tests in Sekundenschnelle durchführen.
• Ein QS-Team verbringt weniger Zeit mit dem Testen und kann sich auf die signifikante Verbesserung der Qualitätskultur konzentrieren.

Kontinuierliche Lieferung

Continuous Delivery ist eine Erweiterung der kontinuierlichen Integration, um sicherzustellen, dass man neue Änderungen an seinen Kunden schnell und nachhaltig freigeben kann. Das bedeutet, dass man neben dem automatisierten Testen auch einen automatisierten Freigabeprozess hat und man seine Anwendung jederzeit per Knopfdruck einsetzen kann. Theoretisch kann man bei kontinuierlicher Lieferung entscheiden, ob man täglich, wöchentlich, vierzehntägig oder nach seinen Geschäftsanforderungen freigeben möchte. Wenn man jedoch wirklich die Vorteile einer kontinuierlichen Lieferung nutzen will, sollte man so früh wie möglich in die Produktion gehen, um sicherzustellen, dass kleine Chargen freigegeben werden, die im Falle eines Problems leicht zu beheben sind.

Kosten

• Man braucht eine starke Basis in der kontinuierlichen Integration.
• Die Bereitstellung muss automatisiert werden. Der Auslöser ist immer noch manuell, aber sobald eine Bereitstellung gestartet ist, sollte kein menschliches Eingreifen erforderlich sein.
• Ein Team wird höchstwahrscheinlich Feature-Flags einbauen müssen, damit unvollständige Features die Kunden in der Produktion nicht beeinträchtigen.

Nutzen

• Die Komplexität der Softwarebereitstellung wurde reduziert. Das Team muss sich nicht mehr tagelang auf eine Veröffentlichung vorbereiten.
• Man kann öfter freigeben und so die Rückkopplungsschleife bei seinen Kunden beschleunigen.
• Der Druck auf die Entscheidungen über kleine Änderungen ist viel geringer, was zu einer schnelleren Iteration führt.

Kontinuierliche Bereitstellung

Das continuous deployment geht einen Schritt weiter als die kontinuierliche Lieferung. Mit dieser Praxis wird jede Änderung, die alle Stufen einer Produktionspipeline durchläuft, an den Kunden freigegeben. Es gibt keinen menschlichen Eingriff, und nur ein fehlgeschlagener Test verhindert, dass eine neue Änderung in der Produktion eingesetzt wird. Kontinuierliche Bereitstellung ist eine ausgezeichnete Möglichkeit, die Rückkopplungsschleife mit den Kunden zu beschleunigen und das Team zu entlasten, da es keinen Release Day mehr gibt. Entwickler können sich auf die Entwicklung von Software konzentrieren. Sie sehen, wie ihre Arbeit Minuten nach Abschluss der Arbeit live geht.

Kosten

• Eine Testkultur muss von ihrer besten Seite sein. Die Qualität der eigenen Testsuite bestimmt die Qualität der eigenen Releases.
• Der Dokumentationsprozess muss mit dem Tempo der Bereitstellung Schritt halten.
• Feature-Flags werden zu einem festen Bestandteil des Prozesses, signifikante Änderungen vorzunehmen, um sicherzustellen, dass man sich mit anderen Abteilungen (Support, Marketing, PR….) abstimmen kann.

Nutzen

• Man kann sich schneller entwickeln, da die Entwicklung nicht für Releases unterbrochen werden muss. Deployment-Pipelines werden bei jeder Änderung automatisch ausgelöst.
• Releases sind weniger riskant und im Problemfall leichter zu beheben, da man kleine Mengen an Änderungen einsetzt.
• Die Kunden sehen einen kontinuierlichen Strom von Verbesserungen, und die Qualität steigt jeden Tag, nicht jeden Monat, jedes Quartal oder Jahr.

Von der kontinuierlichen Integration zur kontinuierlichen Bereitstellung

Wenn ein Team mit einem neuen Projekt beginn, das noch keine Benutzer hat, ist noch einfach, jede Anforderung in die Produktion zu integrieren. Man könnte damit beginnen, seine Implementierungen zu automatisieren und ohne Kunden freizugeben. Dann würde man seine Testkultur hochfahren und sicherstellen, dass man die Code-Deckung erhöht, während man seine Anwendung erstellt. Bis man bereit ist Benutzer zu integrieren, hat man so einen großartigen kontinuierlichen Bereitstellungsprozess.

Aber wenn man bereits eine bestehende Anwendung bei Kunden hat. Man sollte daher mit der Implementierung von Basistests beginnen, die automatisch ausgeführt werden. Man sollte versuchen, seine Bereitstellungen so schnell wie möglich zu automatisieren und eine Stufe zu erreichen, in der die Bereitstellungen automatisch erfolgen. Der Grund dafür ist, dass man durch automatische Implementierungen in der Lage ist, seine Energie auf die Verbesserung der Tests zu konzentrieren. Sobald man Software auf einer täglichen Basis freigibt, kann man sich mit der kontinuierlichen Bereitstellung befassen. Dokumentation, Support, Marketing. Diese Funktionen müssen sich an den neuen Release- Rhythmus anpassen.

Einen Überblick zur Serie Scrum Basics findest du hier: Scrum Basics: Alles auf einen Blick