© Mooshny/Shutterstock.com
Voraussetzungen für Continuous Deployment in Unternehmen

Roadmap einer spannenden Reise


In Unternehmen existiert häufig eine umfangreiche Anwendungslandschaft. Dennoch besteht meist der Wunsch oder Bedarf, regelmäßig neue Versionen der Produkte produktiv zu setzen, um entweder neue Features auszuliefern oder Sicherheitslücken zu schließen. Welche Voraussetzungen für Continuous Deployment erfüllt sein müssen, wird anhand einer Roadmap in diesem Artikel vorgestellt. Dabei werden die Herausforderungen von Verfügbarkeits-, Sicherheits- und Qualitätsanforderungen angesprochen. Spezielles Augenmerk richten wir auf den Aspekt verteilter Verantwortlichkeiten, unabhängig von einer erfolgreichen Etablierung einer DevOps-Kultur.

Was Continuous Deployment betrifft, gibt es unterschiedliche Auffassungen. Eine der Definitionen besagt, dass Continuous Delivery in einer Vorproduktionsstufe ende, sodass Continuous Deployment die Fähigkeit sei, generell in Produktion deployen zu können, unabhängig davon, ob dies manuell per Knopfdruck oder automatisch geschähe (Abb. 1).

Nach einer alternativen Definition umfasst Continuous Delivery auch die manuelle Bereitstellung in der Produktion, während aber bei Continuous Deployment diese Bereitstellung stets automatisch erfolgt.

In diesem Artikel gehen wir von der zweitgenannten Definition aus, sodass nicht die Frage aufkommt, was „manuell per Knopfdruck“ bedeuten kann.

kaps_cd_1.tif_fmt1.jpgAbb. 1: Unterschied Continuous Delivery/Deployment

Schritt 1: Continuous Integration

Continuous Integration (CI) ist eine grundlegende Praktik in der (agilen) Softwareentwicklung. Durch immer kürzer werdende Release- und Produktzyklen ist es zwingend erforderlich, die Integration der Entwicklung kontinuierlich – bei jedem Commit – durchzuführen. Dadurch wird sichergestellt, dass der Code kompiliert werden kann und somit zu jedem Zeitpunkt eine funktionierende Software auslieferbar ist – und auftretende Fehler schnell an die Entwickler zurückgemeldet werden (Fast Feedback bzw. Fail Fast). Automatisierte Tests und Analysen helfen dabei, eine kontinuierlich hohe Qualität des Codes und der Anwendung sicherzustellen. Dabei spielen Continuous-Integration-Server wie Jenkins eine entscheidende Rolle.

Mindestens genauso wichtig ist das Branching-Konzept. Dabei hat sich Trunk Based [1] bewährt, also ein zentraler Branch für alle Commits. Feature Branches sollten weitestgehend vermieden werden, um Merge-Konflikte zu verhindern und ständige Integration zu ermöglichen. Alternative Techniken, um länger andauernde Änderungen dennoch zu ermöglichen, sind unter „Schritt 2a“ und „Schritt 2b“ beschrieben.

Zusätzlich sollten Prüfungen auf Verwundbarkeiten von Abhängigkeiten durchgeführt werden. Im besten Fall werden des Weiteren dynamische Securitytests (DAST) durchgeführt, um Schwachstellen in der eigenen Anwendung frühzeitig zu entdecken.

Schritt 2: Continuous Delivery

Continuous Delivery (CD) als Erweiterung von CI verfolgt das Ziel, kleinere Änderungen an der Software schneller und häufiger auszuliefern. Dadurch wird das Risiko, das große Releases mit sich bringen, verringert und das Vertrauen in die eigene Lieferfähigkeit gesteigert.

Für CD gelten die gleichen Voraussetzungen wie für CI, das heißt, es müssen Alternativen für länger andauernde Änderungen eingeführt werden und es müssen automatisierte Tests existieren. Zusätzlich werden für ein automatisiertes Deployment eventuell Skripte benötigt, abhängig von der eingesetzten Technologie und Infrastruktur. Darüber hinaus kommt der Automatisierung von Datenbankänderungen eine wichtige Rolle zu. Dafür existieren Werkzeuge, wie z. B. Flyway [2], die auch beim Anspruch von Zero-Downtime bei Schemaänderungen durch Konzepte wie Two-phase Migrations [3] unterstützen.

Voraussetzung für CD ist das Entwickeln einer Delivery Pipeline. Welches Werkzeug dafür verwendet wird, hängt von Vorlieben und eventuell anderen Rahmenbedingungen ab. Unabhängig davon ist es unabdingbar, eine geskriptete Pipeline zu haben, die wiederum mit dem Projekt versioniert wird, um eine Reproduzierbarkeit zu ermöglichen. Muss die Entwicklung viele Systeme betreuen, ist eine Einheitlichkeit ebenso wichtig (Unified Deployment). Zu guter Letzt kann eine Einführung von CD organisatorische und kulturelle Herausforderungen mit sich bringen, die deutlich schwieriger zu bewältigen sind als die technischen. Doch diese werden in diesem Artikel nicht weiter betrachtet, da das den Umfang sprengen würde.

Schritt 2a: Branch by Abstraction

Branch by Abstraction betrifft die Entwicklung bzw. die Anwendungspräparation und verfolgt das Ziel, inkrementelle Änderungen an einem bestehenden System durchführen zu können, während die Lieferfähigkeit erhalten bleibt. Diese Methode ist anwendbar, wenn das Team bereits mit Trunk-based Development vertraut ist. Für Änderungen an bestehenden Funktionalitäten wird eine Abstraktionsschicht entwickelt, die zwischen alter und neuer Implementierung agiert. Dadurch können unfertige Implementierungsstände als Dark Deployment einfach ständig mit ausgeliefert werden. Häufig handelt es sich bei diesen Änderungen um crossfunktionale Themen wie Performance, um Framework-Austausch oder größere Refactorings. Reale Tests können beispielsweise mit Hilfe eines Reverse Proxy erfolgen, der im Hintergrund einen Teil der Anfragen an die neue Implementierung leitet (Shadow Traffic). Alternativ wäre auch denkbar, den gesamten Live Traffic sowohl an die bisherige als auch an die neue Implementierung zu leiten.

Dieses Vorgehen ist auch unter den Namen Parallel Change oder Change by Abstraction (Refactoring) bekannt und funktioniert am besten in Kombination mit Feature Toggles, mit denen zwischen alter und neuer Implementierung gewechselt werden kann. Detaillierte Informationen zum Ablauf beim Einsatz dieser Methode ste...

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