Von Continuous Integration zu Continuous Delivery (Teil 1)

Continuous Delivery wird häufig als Weiterentwicklung von Continuous Integration angesehen. Die Idee einer Deployment Pipeline soll dabei helfen, den Schritt von Continous Integration zu Continuous Delivery zu vollziehen.

Deployment Pipeline
Abbildung 1: Deployment Pipeline

Abbildung 1 zeigt eine Deployment Pipeline. Den Anfang dieser Deployment Pipeline stellt das Entwicklungsteam dar, dass zusammen an einem Projekt arbeitet. Bei der Zusammenarbeit von mehreren Entwicklern kommt es häufig zu so genannten Integrationsfehler. Schlecht ist es, wenn diese Integrationsfehler erst spät entdeckt werden, denn in einer späten  Projektphase ist die Beseitigung dieser Fehler deutlich teuer als in einer frühen Phase. Deshalb ist es wichtig, dass nach jeder Code-Integration ein automatisierter Build läuft, der zum Einen überprüft ob sich die Software überhaupt bauen lässt und zum Anderen die Software auf Fehler überprüft. Dabei hilft ein sogenanntes CI-System.

Abbildung 2: Aufbau eines CI-Systems
Abbildung 2: Aufbau eines CI-Systems

Abbildung 2 verdeutlich den schematischen Aufbau eines typischen CI-Systems und den Kreislauf der in einem CI-System vollzogen wird. Das Team führt Änderungen durch. Diese Änderungen werden vom Team an ein Version Control System (VCS) übergeben. Ein Build-Server überprüft kontinuierlich das VCS und führt bei Änderungen einen Build durch. Dieser Build kann erfolgreich sein oder fehlschlagen. Nach einem Build wird das Ergebnis vom Build-Server archiviert und das Ergebnis dem Entwicklungsteam mitgeteilt.

Der Schwerpunkt eines solchen CI Systems liegt also klar beim Entwickler. Dieser kann zufrieden sein, wenn der CI-Server signalisiert, dass der letzte Commit erfolgreich war. Leider wird dabei der Benutzer komplett außen vor gelassen, der mehr an neuer Funktionalität interessiert sein wird. Deshalb muss die Software im nächsten Schritt zum Benutzer kommen. Hierzu ist ein Release nötigt. Ein solches Release stellt in der Regel eine große Herausforderung da, denn dabei sind viele Beteiligte involviert und häufig auch viele manuelle Schritte, was zu einer hohen Fehlerrate führt. Leider vermeiden viele Unternehmen deshalb häufig Releases, was aus Sicht eines Benutzer natürlich ärgerlich ist, da er auf viele Features lange warten muss.

Als begeisterter Software-Entwickler und Consultant kann ich mit diesem Missstand natürlich nicht leben. Deshalb möchte ich euch im Verlauf der Zeit Techniken vorstellen, um neue Features zeitnah und fortwährend nach der Fertigstellung bereitzustellen. Damit werde ich euch zeigen, wie ich in meinem täglichen Alltag das Prinzip Continous Delivery zum Leben erwecken lasse.

Share Button

Eine Antwort auf „Von Continuous Integration zu Continuous Delivery (Teil 1)“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

achtzehn − 3 =