© Excellent backgrounds/Shutterstock.com
Continuous Delivery und die Datenbank

Unterschätzte Herausforderungen


Bessere Qualität, schnelles Feedback vom Kunden, ständige Innovation und niedrigere Kosten. Dies sind nur einige der Vorteile, die uns die schöne neue Welt von Continuous Delivery verspricht. Welche Auswirkungen ein solches Vorgehen allerdings auf unsere Datenbanken hat, wird nur allzu oft kurz und elegant übersprungen. Dieser Artikel zeigt verschiedene Techniken im Umgang mit unseren Produktivdaten bei mehreren Releases pro Tag und verschweigt (ausnahmsweise) auch nicht deren Nachteile.

Bei Continuous Delivery wird durch die Verkürzung der Zeitspanne zwischen zwei aufeinanderfolgenden Softwarereleases versucht, möglichst schnell Feedback von den Endnutzern zu bekommen. Dies kann bedeuten, dass mehrmals am Tag eine neue Anwendungsversion in die Produktivumgebung eingespielt wird. Durch dieses Vorgehen können mögliche Kommunikationsprobleme zwischen den Entwicklern und den Kunden frühzeitig erkannt werden. Wir alle kennen die Probleme, die aus unzureichender Kommunikation entstehen können: „Das hatten wir doch so besprochen“ oder „Das ist doch selbstverständlich, dass dieser Teil so funktionieren und so schnell wie möglich fertiggestellt werden muss“ sind Sätze, die wahrscheinlich die meisten Entwickler schon einmal gehört haben.

„Nicht-Techies“ können ihre Wünsche meist am besten anhand der laufenden Software in einem produktiven Umfeld kundtun. Indem wir die Zeit zwischen der ersten Idee eines neuen Features und der lauffähigen Software unter anderem durch Automatisierung minimieren, bekommen wir deutlich schnellere Reaktionszeiten und vermindern dadurch gleichzeitig das Projektrisiko. Mit Continuous Delivery werden wir in die Lage versetzt, sehr schnell Änderungen in der Produktionsumgebung durchzuführen. Dadurch werden auch die Auswirkungen eventueller Kommunikationsprobleme minimiert. Der geänderte Code kann jederzeit nachgebessert oder sogar wieder ganz entfernt werden. Wir müssen nicht mehr auf das nächste Release warten, das in klassischen Releaseprozessen vielleicht erst ein Jahr später anstehen würde.

Technische Herausforderungen

Die gerade beschriebenen Vorteile hören sich zunächst sehr verlockend an. Für die praktische Umsetzung von Continuous Delivery benötigen wir eine automatisierte Build Pipeline, die uns ermöglicht, Änderungen per Knopfdruck automatisch in die Produktionsumgebung zu übernehmen. Bevor wir uns allerdings voller Enthusiasmus an die Umsetzung einer solchen Pipeline machen, sollten wir zuvor noch einen Blick auf die technischen Herausforderungen und die damit aufkommenden neuen Fragestellungen werfen.

Zunächst einmal müssen wir uns von dem Gedanken lösen, dass jedes Produktions-Deployment auch automatisch mit der Freigabe eines neuen Features verbunden ist. Im Continuous-Delivery-Umfeld ist es nicht ungewöhnlich, dass dreißig oder mehr Deployments pro Tag stattfinden. Da ist es leicht ersichtlich, dass nicht jedes dieser Deployments ein vollständiges Feature beinhalten kann. Vielmehr ist es gängig, dass neue Features über viele Deployments hinweg nach und nach in die Produktion überführt werden. Technisch stehen für diese Herausforderung verschiedene erprobte Lösungsmöglichkeiten zur Verfügung. Sie reichen vom Einsatz von Feature-Branches [1] über das programmatische Ein- und Ausschalten von Features per Feature­Toogles [2] bis hin zu Branch by Abstraction [3].

Auch beim Thema Rollback müssen wir umdenken. Bei einem einzigen Release pro Jahr ist es sehr wichtig, dass die Anwendung anschließend wieder funktionsfähig ist, entsprechend wird meist viel Aufwand in die Ausarbeitung von Rollback-Strategien gesteckt. Nur so kann das notwendige Vertrauen hergestellt werden, um das jährliche Produktions-Deployment zu wagen. Bei mehreren Deployments pro Tag ist es nicht mehr möglich, diese vertrauensbildende Maßnahme immer vorzusehen. Es kann daher für die einzelnen Deployments keine Rollbacks mehr geben. Falls in der neuen Version ein Bug auftritt, wird dieser einfach mit dem nächsten Deployment behoben. Wir verzichten also in aller Regel auf die Möglichkeit, bereits gemachte Änderungen wieder zurückzunehmen und bauen stattdessen immer weiter auf bereits in der Produktion befindlichen Code auf. Da sich Fehler dennoch nicht vollständig vermeiden lassen, ist es wichtig, dass unsere Anwendung mit Fehlern in der Produktion umgehen kann und sich vor allem robust gegenüber Fremdsystemschnittstellen zeigt. Bekannt geworden ist dieser Ansatz unter dem Namen „Resilient Softwaredesign“.

Continuous Delivery kann nur dann erfolgreich funktionieren, wenn wir auf dem Weg einer Änderung in Richtung Produktion geeignete Qualitätssicherungsmaßnahmen vorsehen. Welche Sicherungsmaßnahmen hierbei die richtigen sind, ist von Projekt zu Projekt unterschiedlich. Ein Continuous-Integration-Server, der automatisch jeden Build und somit jede Codeänderung ohne weitere Checks direkt in die Produktion überführt, genügt den Qualitätsanforderungen dabei allerdings nicht. Stattdessen benötigen wir einen mehrstufigen Qualitätssicherungsprozess. Als Teil dieses Prozesses haben sich neben den klassischen Unit Tests auch Code...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang