Continuous Integration und Continuous Delivery

Mit Continuous Integration, Delivery und Deployment können sich Entwickler mehr auf ihre eigentlichen Aufgaben konzentrieren. Die Validierung und Integration des Codes erfolgt automatisiert.

Bei Continuous Integration (CI) und Continuous Delivery (CD) gibt es genau festgelegte Arbeitsabläufe, die definieren, in welchen Zeiträumen der Code automatisiert getestet und in die Produktionsumgebung integriert wird. Die automatisierten Tests beginnen direkt mit dem Einchecken in die Codeverwaltung.

Das Einchecken erzeugt eine neue Version, die entsprechend automatisiert getestet wird, unter Umständen wird auch das Verteilen in eine Produktionsumgebung gesteuert. Damit CI genutzt werden kann, müssen die Entwickler mit einer gemeinsamen Code-Basis arbeiten. Um diese gemeinsame Basis sicherzustellen, wird der Code regelmäßig eingecheckt und durch eine Versionsverwaltung eingegliedert.

Continuous Integration sorgt also dafür, dass Änderungen am Quellcode durch automatisierte Tests inklusive schneller Feedbacks erfolgen können. Entwickler erhalten eine grundlegende Sicherheit der Stabilität ihres Codes. Da das Vorgehen immer gleich ist und die meisten Vorgänge automatisiert ablaufen, können sich in die Abläufe selbst so gut wie keine Fehler einschleichen. Die Qualität der Anwendungen wird besser, die Bereitstellung erfolgt schneller.

Continuous Integration und Nightly Builds

Arbeiten Unternehmen mit Continuous Integration, sollte in regelmäßigen Abständen dafür gesorgt werden, dass der Code tatsächlich eingecheckt wird. Bei diesem Vorgang wird eine neue Version erzeugt, was wiederum automatisierte Tests auslöst. Dieser Vorgang ist vor allem bei der Arbeit in Teams wichtig.

Viele Open-Source-Projekte, aber auch andere Entwickler, arbeiten dazu mit „Nightly Build“-Versionen. Diese umfasst den Stand der Entwicklung zum Abschluss des Tages. Continuous Integration arbeitet in den meisten Fällen mit teils noch kürzeren Entwicklungsphasen. Je kürzer die Integrations-Intervalle sind, umso stabiler wird die Entwicklung, da keine Entwicklungsschritte verloren gehen, und der neuste Code immer erfasst und getestet werden kann.

Im Rahmen des Check-Ins wird der Code im Rahmen vollständig automatisierter Abläufe geprüft. Zugriff auf die Testergebnisse und die Möglichkeiten zum Test haben neben der Entwicklungsabteilung auch andere Anwender. Durch die zentrale Prüfung haben auch in DevOps-Umgebungen alle relevante Mitarbeiter immer einen kompletten Überblick über den aktuellen Entwicklungsstand.

Da die Anwendungen bereits in der Entwicklung getestet werden, erhalten die Entwickler regelmäßiges Feedback. Auf diese Weise lassen sich Fehler und Probleme schneller erkennen, sodass Korrekturen und Reverts wieder in die Entwicklung mit einfließen. Wichtig ist dabei, dass die Testumgebung im Wesentlichen der Produktionsumgebung entspricht, natürlich nicht in der gleichen Skalierung. Außerdem müssen alle beteiligten Produkte auf einem aktuellen Stand gehalten werden.

Continuous Delivery baut auf CI auf

Continuous Delivery (CD) ist der nächste Schritt, wenn Unternehmen auf Continuous Integration (CI) setzen. Damit CD eingesetzt werden kann, muss die Software das Implementieren von neuen Features in regelmäßigen Abständen ermöglichen.

Durch das Sicherstellen dieser Priorität können regelmäßig neue Versionen im Rahmen von CI implementiert und mit CD bereitgestellt werden. Damit erreichen Unternehmen also eine vollständige Planung und teilweise auch Automatisierung der Bereitstellung von neuen Versionen.

Einfach ausgedrückt ist Continuous Delivery die konsequente Weiterführung von Continuous Integration, da hier auch die Bereitstellung geregelt ist, nicht nur Entwicklung und Test. CD integriert agile Entwicklung also in die Produktion. Wie bei CI spielt auch bei CD die Automatisierung eine wesentliche Rolle. Nur dadurch ist sichergestellt, dass der komplette Entwicklungsprozess effizient, schnell und fehlerfrei durchläuft.

Vorzugsweise sollte dabei auch die Bereitstellung der Test- und Produktionsumgebung automatisiert ablaufen. So ist sichergestellt, dass alle beteiligten Komponenten exakt den Stand widerspiegeln, den die einzelnen Arbeitsabläufe in CI und CD entsprechen. Auch die Produktionsumgebung sollte den gleichen Stand abbilden. Hier helfen Tools wie Ansible, Chef, Puppet oder Saltstack. Durch die Pipeline wird sichergestellt, wie die Bereitstellung des neuen Codes zu erfolgen hat.

Damit die Vorgänge funktionieren, müssen die Tests der neuen Features schnell und automatisiert erfolgen. Entwickler erhalten dadurch regelmäßig Feedback, das wiederum in neuen Code integriert werden kann. Alle vorhandenen Versionen müssen dazu ohne Probleme schnell und einfach bereitstellbar sein. Vor allem CD baut stark auf der DevOps-Idee auf, da bei der Bereitstellung neuer Versionen in der Produktivumgebung natürlich auch die Anwender, Administratoren und anderen IT-Angestellten eingebunden werden müssen.

Um Fehler im Bereitstellungsprozess zu vermeiden, erfolgt auch CD automatisiert. Zusammen mit der automatisierten CI ergibt sich eine Deployment-Pipeline, in der neue Features schnell in den Code integriert und getestet werden, und in der die meisten Bereiche automatisiert werden.

Durch CI, CD und der damit einhergehenden Automatisierung entsteht eine Transparenz im Entwicklungsprozess. Die Versionen und Softwarestände sowie deren Funktionen sind jederzeit nachvollziehbar. Das gilt auch für die Testergebnisse und damit das zu erwartende Ergebnis bei der Bereitstellung im Produktionsbetrieb. Durch die wesentlich schnelleren Bereitstellungszyklen erhalten Entwickler schnell Feedback zur Anwendung, das für eine bessere Entwicklung genutzt werden kann.

Continuous Delivery versus Continuous Deployment

Eine weitere Steigerung des Bereitstellungsprozesses wird mittels Continuous Deployment erreicht. Während bei Continuous Delivery die Entscheider festlegen können, wann neue Versionen und damit neue Funktionen in die Produktionsumgebung überführt werden, wird beim Einsatz von Continuous Deployment auch dieser Prozess vollständig automatisiert.

Neue Features und damit Versionen werden automatisch bereitgestellt. Es findet kein Entscheidungsprozess mehr statt, wann eine neue Version oder ein neues Feature in der Produktionsumgebung zur Verfügung gestellt wird. Sobald eine neue Version eingecheckt wird, starten die notwendigen Prozesse, um eine neue Version der Anwendung auch in der Produktionsumgebung bereitzustellen.