Con­ti­nuous In­te­gra­ti­on vs. Con­ti­nuous Delivery vs. Con­ti­nuous De­ploy­ment – Soft­ware­ent­wick­lungs­mo­del­le im Überblick

Soft­ware­ent­wick­lungs­pro­zes­se sind teuer. Ins­be­son­de­re dann, wenn der fertige Code sich nicht rei­bungs­los in die be­stehen­de Software einbinden lässt, schießen die Kosten für die Ent­wick­lung in die Höhe. Abhilfe schaffen die modernen Ansätze Con­ti­nuous In­te­gra­ti­on, Delivery und De­ploy­ment (kon­ti­nu­ier­li­che In­te­gra­ti­on, Lieferung und Be­reit­stel­lung). Diese setzen auf mehrfache Va­li­die­rung des Codes bereits während seiner Ent­wick­lung. Das Arbeiten in mehreren kleineren Ent­wick­lungs­pha­sen erlaubt es außerdem, dem Kunden Pro­to­ty­pen des ge­wünsch­ten Produkts zu liefern. So kann dieser während der gesamten Ent­wick­lung seine An­for­de­run­gen anpassen und schauen, ob die Software die ge­wünsch­te Form annimmt.

Ihren Ursprung haben die modernen Soft­ware­ent­wick­lungs­mo­del­le allesamt im Konzept der agilen Soft­ware­ent­wick­lung. Hierbei handelt es sich um einen Ansatz, der die Ent­wick­lung von Software nicht nur be­schleu­ni­gen, sondern auch trans­pa­ren­ter machen soll. Ziel der agilen Ar­beits­wei­se ist es, Software zu ent­wi­ckeln, die der Kunde wirklich benötigt. Durch Pro­to­ty­pen, die während jeder Phase der Ent­wick­lung zur Verfügung gestellt werden, kann der Auf­trag­ge­ber über­prü­fen, ob die Software tat­säch­lich das tut, was sie soll, und ob sie mit be­stehen­der Software kom­pa­ti­bel ist. Auch Kun­den­wün­sche, die erst im Ent­wick­lungs­pro­zess entstehen, können bei agilen Methoden be­rück­sich­tigt werden.

Der Trend zur agilen Ent­wick­lung setzt sich auch in Un­ter­neh­mens­kul­tu­ren fort. Es gibt mehrere Ansätze, die in­ner­be­trieb­lich für eine Be­schleu­ni­gung von Ent­wick­lungs­pro­zes­sen sorgen sollen. Einer davon ist DevOps. Die Be­zeich­nung setzt sich aus den Wörtern „De­ve­lo­p­ment“ (Ent­wick­lung) und „Ope­ra­ti­ons“ (Or­ga­ni­sa­ti­on) zusammen. Ziel dieser Un­ter­neh­mens­kul­tur ist es, dass die ei­gent­li­chen Ent­wick­lungs­teams während der gesamten Soft­ware­ent­wick­lungs­pha­se und darüber hinaus mit den Or­ga­ni­sa­ti­ons­teams eines Betriebs zu­sam­men­ar­bei­ten. So werden Probleme der In­te­gra­ti­on von Software von vorn­her­ein vermieden. Auch die Wartung und Be­reit­stel­lung der fertigen Programme werden er­leich­tert. Neben einer fort­lau­fen­den Ent­wick­lung setzen Vertreter von DevOps auf Con­ti­nuous In­te­gra­ti­on und Con­ti­nuous De­ploy­ment.

Beim Konzept der kon­ti­nu­ier­li­chen In­te­gra­ti­on wird das Ziel verfolgt, Än­de­run­gen an einem Soft­ware­pro­jekt möglichst schnell in die gesamte Software ein­zu­fü­gen. Der Code wird also täglich von den Ent­wick­lern ak­tua­li­siert. Hierzu werden neben ver­schie­de­nen Con­ti­nuous-In­te­gra­ti­on-Tools vor allem Ver­sio­nen­kon­troll­sys­te­me wie GitHub genutzt. Diese erlauben es, lokale Kopien des gesamten Projekts auf dem eigenen Rechner zu speichern. Die Pro­gram­mie­rer können Än­de­run­gen am Code vornehmen und diese im Ver­sio­nen­kon­troll­sys­tem hochladen. An­schlie­ßend kann das gesamte Programm ver­schie­de­nen Tests un­ter­zo­gen werden. Auf diese Weise können In­te­gra­ti­ons­pro­ble­me schon im Vorhinein vermieden werden.

Das Konzept Con­ti­nuous Delivery geht noch einen Schritt weiter als der Ansatz der kon­ti­nu­ier­li­chen In­te­gra­ti­on: Der Code wird nicht nur täglich ak­tua­li­siert und jede Änderung schnells­tens in­te­griert, sondern dem Kunden wird darüber hinaus möglichst früh ein Prototyp zur Verfügung gestellt. Der Vergleich Con­ti­nuous In­te­gra­ti­on vs. Con­ti­nuous Delivery zeigt, dass der Fokus bei der kon­ti­nu­ier­li­chen Lieferung vor allem auf dem Feedback des Kunden liegt. Durch die frühe Aus­lie­fe­rung von fertigem Teil-Code ist es möglich, die Sys­tem­soft­ware in ihrer realen Umgebung zu testen. Alles, was dem Kunden noch nicht gefällt, kann im weiteren Ent­wick­lungs­pro­zess angepasst werden. Wenn der Teil-Code dem Kunden gefällt, wird er im Anschluss manuell be­reit­ge­stellt.

Einen ähnlichen, aber noch er­wei­ter­ten Ansatz verfolgt Con­ti­nuous De­ploy­ment. Bei diesem Verfahren werden au­to­ma­ti­sier­te Tests genutzt, die direkt in den Ent­wick­lungs­pro­zess ein­ge­bun­den werden. Die Ge­gen­über­stel­lung Con­ti­nuous Delivery vs. Con­ti­nuous De­ploy­ment ver­deut­licht, dass bei der kon­ti­nu­ier­li­chen Be­reit­stel­lung keine Zeit­ver­zö­ge­rung zwischen Test- und Re­lease­zeit­punkt des Codes vorhanden ist. Aufgrund der aus­führ­li­chen Test-Frame­works müssen die Ent­wick­ler nicht einmal mehr auf das Feedback des Kunden warten, sondern können ihren Teil-Code nach der Ent­wick­lung direkt au­to­ma­ti­siert be­reit­stel­len.

Welches Ent­wick­lungs­mo­dell sich am besten eignet, hängt ganz von den spe­zi­fi­schen An­for­de­run­gen an das Projekt ab. Insgesamt bieten alle drei Modelle jedoch die meisten Vorteile, wenn der Kunde und die Ent­wick­ler eng zu­sam­men­ar­bei­ten können.

Die kon­ti­nu­ier­li­che Be­reit­stel­lung ist aufgrund der auf­wen­di­gen Test­ver­fah­ren zwar teuer, führt aber dazu, dass die Kunden tägliche Ver­bes­se­run­gen der Software wahr­neh­men können. Außerdem wird der Ent­wick­lungs­pro­zess be­schleu­nigt, da er zu keinem Zeitpunkt un­ter­bro­chen wird. So ist es oft sogar möglich, die Mehr­kos­ten für die Test-Frame­works am Ende wieder ein­zu­spa­ren. Bei der kon­ti­nu­ier­li­chen Lieferung hat der Kunde selbst noch sehr viel Hand­lungs­spiel­raum, sodass An­for­de­run­gen ohne Nachteile auch erst im Nach­hin­ein spe­zi­fi­ziert werden können. Kleine Än­de­run­gen am Code gehen ebenfalls leicht von der Hand.

Im Vergleich Con­ti­nuous In­te­gra­ti­on vs. Con­ti­nuous Delivery zeigt sich, dass die kon­ti­nu­ier­li­che Lieferung gänzlich auf die zwi­schen­zeit­li­che Ver­öf­fent­li­chung des Codes ver­zich­tet. Dieser Ar­beits­pro­zess lohnt sich daher vor allem für kleinere Projekte, bei denen eine ständige Ak­tua­li­sie­rung nicht relevant oder sogar hin­der­lich ist.