Docker Container sind inzwischen ein etabliertes Werkzeug für das Deployment von Anwendungen. In diesem Artikel beleuchten wir die Vorteile eines Continuous Integration und Continuous Deployment Prozesses mit Docker.
Continuous Integration
Sobald mehr als ein Entwickler an einer Anwendung arbeitet, stellt sich die Herausforderung sicherzustellen, dass alles zusammenpasst. Auf der einen Seite hilft uns dabei ein Versionskontrollsystem wie git. Jeder Entwickler committed seine Änderungen in seinem eigenen Rhythmus. Sobald er oder sie sicher ist, dass die Änderungen und Ergänzungen in den allgemeinen Codestand übertragen werden können, werden die Änderungen gepusht. Zu diesem Zeitpunkt muss sichergestellt werden, dass diese Änderungen funktionieren und keine Schäden am Bestandscode verursachen. Auch muss sichergestellt werden, dass die Änderungen zu den Änderungen der Kollegen passen.
Bevor ein Entwickler seine eigenen Änderungen pushed, müssen lokal die automatisierten Tests ausgeführt werden. Dies stellt sicher, dass zumindest aus Sicht des einzelnen Entwicklers alles in Ordnung ist. Doch bei einem ausreichend großen Softwaresystem genügt dies häufig nicht. Es muss auf jeden Fall sichergestellt werden, dass die Integration der Änderungen in das Gesamtsystem keinen Schaden anrichtet. Hier kommt der Continuous Integration Prozess ins Spiel.
Auf einem Continuous Integration Server werden nach jedem Push alle Bestandteile des Systems integriert. Das bedeutet, es wird die gesamte Codebasis übersetzt. Bereits hierbei können Fehler zutage treten, wenn eine lokale Änderung Probleme in einem weiter entfernten Codebereich verursacht, die der einzelne Entwickler nicht überblickt hat. Im Anschluss an den Build Schritt werden sämtliche automatisierten Tests ausgeführt. Damit wird sichergestellt, dass die Korrektheit gewahrt bleibt. Es muss sichergestellt werden, dass Fehler entdeckt werden, unabhängig davon, welche Tests der Entwickler lokal auf seiner Maschine ausgeführt hat. Im Eifer des Gefechts wird die lokale Testausführung manchmal vergessen oder nicht alle Tests werden ausgeführt. Somit stellt die Testausführung auf dem Continuous Integration Server ein Sicherheitsnetz dar, das Fehler entdeckt, unabhängig vom einzelnen Entwickler und seiner Sorgfalt.
Als Ergebnis des Continuous Integration Prozesses steht ein deployfähiges Produkt zur Verfügung. Im Kontext von Docker sind dies ein oder mehrere Docker Images, die in eine Registry hochgeladen werden. Gegen diese Images sollten weitere automatisierte Tests ausgeführt werden. In der Regel sind die Integrations- oder Systemtest.
Im Anschluss an den erfolgreich durchlaufenen Continuous Integration Prozess kann es zum nächsten Schritt gehen, dem Deployment.
Continuous Deployment
Nachdem durch den Continuous Integration Prozess eine neue Version des Softwaresystems in die Registry geladen wurde, muss diese Version deployed werden. Dies kann zunächst auf ein Staging- oder Testsystem erfolgen, damit der Product Owner bzw. die Qualitätssicherung das Ergebnis begutachten können. Unabhängig davon, ob jede einzelne Version durch diese Personen getestet wird, muss das Deployment auf das Staging- bzw. Testsystem vollautomatisiert erfolgen. Zum einen ist dies effizienter als ein Deployment per Hand. Zum anderen stellt die Automatisierung sicher, dass dabei keine Fehler passieren. Alle für das Deployment erforderlichen Arbeitsschritte werden vollständig automatisiert.
Wird die Version des Softwaresystems für den Echtbetrieb freigegeben, erfolgt ein automatisiertes Deployment in die Produktionsumgebung.
Je nach Grad der Testautomatisierung kann auch direkt in die Produktionsumgebung deployed werden. Zunächst werden die Entwickler sich damit vermutlich schwertun, aus Angst, dass unentdeckte Fehler in die Produktion gelangen.
Doch dies ist kein Problem, sondern eine Lösung. Je mehr Sorgfalt jeder einzelne Entwickler in die Testautomatisierung und die Testabdeckung steckt, desto höher wird die Qualität des Produkts. Gleichzeitig steigt damit die Zuversicht, dass die Fehlerrate sich in engen Grenzen hält.
Das kontinuierliche Bereitstellen jeder neuen Version des Produktes fordert die Entwickler heraus, sich auf die Qualität des Produktes und des Entwicklungsprozesses zu fokussieren. Dies fällt um so leichter, wenn konsequent nur an einem Feature zur gleichen Zeit gearbeitet wird. Statt viele lose Enden offen zu haben, die nur mit großer Verzögerung beim Endkunden ankommen, wird so Schritt für Schritt Nutzen geliefert.
Zwischenfazit
Ein gut laufender Prozess aus Continuous Integration und Continuous Deployment stellt sicher, dass Probleme frühzeitig erkannt werden. Das Ziel liegt in einem kontinuierlichen Prozess, der schrittweise eine Anforderung nach der anderen zum Endkunden bringt. Code, Tests und neue Versionen entfalten ihre Wirkung erst, wenn sie beim Kunden ankommen. Der Prozess aus Continuous Integration und Continuous Deployment soll die Entwickler herausfordern, sich auf die Qualität des Produktes zu fokussieren.
Docker
Mit Docker steht ein mächtiges Werkzeug zur Verfügung, das den kontinuierlichen Prozess drastisch vereinfacht. Der Schlüssel liegt hier in der Reproduzierbarkeit. Durch den Einsatz von Docker steht eine kontinuierlich reproduzierbare Umgebung bereit. Jedes Docker Image beginnt in einer klar definierten Umgebung. Es tauchen keine Überraschungen auf, weil sich plötzlich die Umgebung geändert hat, in der das Softwaresystem ausgeführt wird. Solange niemand eine andere Version der zugrundeliegenden Images einstellt, bleibt alles reproduzierbar und immer gleich.
Der Umstieg auf neuere Versionen der Umgebung erfolgt jeweils gezielt. Die Testautomatisierung stellt dabei sicher, dass das System auch in der aktualisierten Umgebung korrekt ausgeführt wird. Dies gilt auch für externe Ressourcen, von denen das System abhängig ist. Es kommen immer wieder definiert dieselben Versionen zum Einsatz.
Benötigt das System bspw. eine Postgres Datenbank, kommt immer dieselbe Version zum Einsatz, unabhängig davon, auf welche Server das System deployed wird. Der Server muss die Ressourcen nicht selbst bereitstellen, sondern auch diese werden als Docker Container deployed. So kann das Gesamtsystem auf Knopfdruck auf mehr oder weniger beliebige Server deployed werden, auf denen lediglich eine Docker Umgebung bereitstehen muss. Ein weiterer Vorteil: Test- und Produktionsumgebung unterscheiden sich auf diese Weise nicht. Dies stellt sicher, dass alle Tests so nah an der Produktion ausgeführt werden, wie möglich.
Fazit
Solange ein Softwareentwicklungsprozess nicht klar definiert ist, besteht an vielen Stellen die Möglichkeit für Fehler. Jedes Team muss den Prozess für sich definieren und aufsetzen. Den Anfang macht die Einführung einer Versionskontrolle. Darauf aufbauend wird ein Continuous Integration Prozess aufgesetzt. Schon dieser führt dazu, dass weniger Fehler unentdeckt bleiben. Der CI Prozess nimmt die Handarbeit und Sorgfalt jedes einzelnen Entwicklers ein gutes Stück aus dem Prozess heraus.
Auf dem CI Prozess baut dann das kontinuierliche Deployment auf. Es stellt sicher, dass jeder Entwickler herausgefordert wird, ordentlich zu arbeiten. Denn potenziell landet ein Push direkt in der Produktionsumgebung. Sobald mir das als Entwickler klar ist, werde ich im eigenen Interesse für eine hohe Testabdeckung sorgen.
Wer noch nicht davon überzeugt ist, dass Continuous Deployment praktisch unverzichtbar ist, mag vielleicht einen Blick in das Buch Accelerate werfen. Dort wird der Zusammenhang von Continuous Deployment und Unternehmenserfolg klar nachgewiesen.
Den praktischen Umgang mit Docker kannst Du in unserem Seminar lernen.
German 
English