Die Cloud bietet viele Möglichkeiten – schnelle und einfachere Deployments gehören definitiv dazu. Damit entsteht schnell auch der Wunsch, neue Features direkt in Form eines Feature-Branch-Deployment bereitstellen zu können. Welche Komplexität dahinter steckt und vor allem, wann der Einsatz sinnvoll ist, wollen wir uns in diesem Artikel mal etwas genauer anschauen.
Bei der Migration in die Cloud ist vielen Kunden ein Thema besonders wichtig: Feature-Branch-Deployments. Das Ziel ist, einzelne Feature schnell zur fachlichen Abnahme oder zu Testzwecken bereitstellen zu können – ganz losgelöst vom üblichen Release-Prozess und den dazugehörigen Stages.
Wie der Name schon sagt, leitet sich so ein Deployment von der Verwendung von Branches in Werkzeugen wie Git oder Subversion ab. Im Folgenden werden diese vereinfacht als Feature-Deployments bezeichnet.
Traditionell erwies sich die Umsetzung von Feature-Deployments außerhalb der Cloud häufig als eine große Schwierigkeit. Gründe sind meist die fehlenden Hardware-Kapazitäten, aber auch die nicht vorhandene Automatisierung des Deployment-Prozesses. Mit dem Gang in Cloud werden diese Probleme meist gelöst und die Hoffnung kommt auf, dass auch die Umsetzung von Feature-Deployments nur ein weiterer kleiner Schritt ist
Stellt ein Kunde nun also die Frage, ob mit der Cloud denn nun wirklich alles besser wird, ist die pauschale Antwort natürlich erstmal: Ja! – Bei der Erläuterung, was genau zu beachten ist, um erfolgreich Feature-Deployments zu umzusetzen, werden die meisten Kunden jedoch etwas zurückhaltender. Der Teufel steckt auch hier leider wieder im Detail. Je nach Komplexität des Features und des eigentlichen Zwecks des Deployments, ergeben sich durchaus verschiedene Herausforderungen, die es zu meistern gilt.
Auf dem Papier ist die Umsetzung von Feature-Deployments einfach. Die gesamte Anwendung wird inklusive des neuen Features zusätzlich – quasi neben den üblichen Release-Stages – als Deployment bereitgestellt. Entwickler, Tester oder Fachexperten können das Feature so isoliert in einer produktionsnahen Umgebung anschauen, bewerten und fachlich sowie technisch abnehmen.
Für einzelne Features ein gesamtes Deployment durchzuführen, kommt jedoch mit gewissem Aufwand daher. Folgt die Anwendung etwa einer Microservice-basierten Architektur, besteht das Deployment tatsächlich aus einer Reihe von Teil-Deployments, abhängig von der Anzahl der Services. Zusätzlich können weitere Komponenten, wie etwa Datenbanken, das Deployment weiter verkomplizieren. Um ein Feature ausgiebig testen zu können, werden oft auch realistische Daten benötigt. Ein Spiegeln der bestehenden Daten der einzelnen Services in das Feature-Deployment kann daher notwendig sein.
Zudem ist ein vollständiges Deployment mit einem hohen zeitlichen, aber auch finanziellen Aufwand verbunden – je größer die Anwendung, desto größer ist auch dieser Aufwand. Dieser lässt sich häufig nur für die permanenten Release-Stages oder aufwändige, langlebige Features rechtfertigen. Bei kleineren Features übersteigt der Aufwand häufig den tatsächlichen Nutzen.
Um den Aufwand für das Deployment geringer halten zu können, lohnt ein Blick auf das eigentliche Feature. Nicht jedes Feature benötigt ein vollständiges Deployment. Idealerweise reicht auch ein vereinfachtes Teil-Deployment, um das Feature ausgiebig zu testen.
Ein Feature, in dem lediglich die Farbe eines Buttons im Frontend verändert wird, stellt ein gutes Beispiel für ein vergleichsweise einfaches Feature-Deployment dar. Da sich die Änderung lediglich auf das Frontend bezieht, muss auch nur dieses im Deployment enthalten werden. Die Abhängigkeiten des Frontends müssen hier nicht Teil des Deployments sein. Das Frontend kann stattdessen direkt mit dem Backend in den vorhandenen Release-Stages (z.B. der DEV-Stage) kommunizieren (siehe Abbildung 1). Gleichzeitig kann das Deployment so auch von einer bereits gefüllten Datenbank profitieren. Der zeitliche Aufwand sowie die Kosten sind im Vergleich zu einem vollständigen Deployment deutlich geringer.
In einem Feature hingegen, das die API eines Services verändert, ist die Komplexität des Deployments mitunter deutlich höher. Insbesondere, wenn viele Teile der Anwendung abhängig vom veränderten Service sind. Um das neue Feature im Rahmen der Gesamt-Anwendung sinnvoll zu testen, reicht es nicht aus, nur den veränderten Service bereitzustellen. Auch alle Bestandteile, die direkt oder indirekt von diesem abhängen, müssen im Feature-Deployments enthalten sein. Im Zweifel zieht sich dies vom Frontend bis zum veränderten Service (siehe Abbildung 2). Das Deployment kann deutlich weniger von den vorhandenen Release-Stages profitieren. Die Konsequenz sind höhere Kosten und Zeitaufwand beim Deployment.
Neben der Betrachtung der Komplexität lohnt häufig auch ein Blick auf den eigentlichen Grund für ein Feature-Deployment. Woraus ein Deployment bestehen muss, hängt auch davon ab, welches Ziel damit erreicht werden soll.
Der wohl häufigste Grund ist die Vermeidung eines Feature-Staus. So ein Stau kann entstehen, wenn eine Anwendung zunächst eine Reihe von Release-Stages durchlaufen muss, bevor diese dem Benutzer zur Verfügung gestellt wird. Ein Release erreicht erst die nächste Stage, wenn die gesamte Anwendung mit allen Features erwartungsgemäß funktioniert. Diese Abnahme kann etwa durch den Fachbereich, durch Tester oder die Entwickler selbst erfolgen. Verzögert sich die Abnahme oder scheitert diese gar, müssen die entsprechenden Probleme zunächst beseitigt werden. Erst dann kann das Release in die nächste Stage wandern. Hängt das Problem an einigen wenigen Features, werden andere bereits abgenommene Features blockiert und können somit nur verzögert beim Benutzer landen.
Um so einen Feature-Stau zu vermeiden, sollen neue Features frühzeitig und unabhängig vom normalen Release-Prozess abgenommen werden. Ein Feature-Deployment kann hier Abhilfe schaffen. Erst wenn die Abnahme dort erfolgreich war, wird das Feature den regulären Prozess durchlaufen. Die Abnahme in den einzelnen Release-Stages beschränkt sich dann weitestgehend auf die Integration der verschiedenen Features, um so sicherzustellen, dass die Anwendung im Zusammenspiel funktioniert.
Ein weiterer Grund für Feature-Deployment ergibt sich aus dem Entwicklungsprozess. Insbesondere wenn die Anwendung aus verschiedenen Microservices besteht, haben die Entwickler den Bedarf frühzeit ihre Änderungen im Zusammenspiel mit anderen Services zu testen. Dies gilt speziell dann, wenn Features Auswirkungen auf mehrere Services haben. Verändert ein Feature die API eines Services, entsteht mitunter die Notwendigkeit auch Änderungen an anderen Services vorzunehmen.
Durch Feature-Deployments können noch während der Entwicklung Zwischenstände bereitgestellt werden, sodass die Entwickler des abhängigen Service gegen ein reales Deployment entwickeln und testen können. Die Kollaboration zwischen Entwicklern gestaltet sich so deutlich effizienter.
Ein großer Vorteil dieser Art des Deployments ist die geringere Komplexität. Anders als bei der Abnahme eines Features ist es hier nicht notwendig, alle Bestandteile der Anwendung bereitzustellen – besonders indirekte Abhängigkeiten können oft ignoriert werden (siehe Abbildung 3). Auch der Zeit- und Kostenaufwand fällt durch das einfach Deployment geringer aus. Zudem reduziert das frühzeitige Testen der Integration verschiedener Services, mögliche Probleme, die ansonsten erst im Release-Prozess aufgefallen wären.
Die Migration in die Cloud geht oft mit einem erhöhten Automatisierungsgrad und nahezu unbegrenzten Hardware-Kapazitäten einher. Dadurch entstehen viele Möglichkeiten, die es vorher nicht gab. Für viele gehören auch Feature-Deployments dazu. Dennoch sollte der Einsatz wohlüberlegt sein und auch anderen Ansätzen wie Feature-Flags gegenübergestellt werden.
Für jedes einzelne Feature ein vollständiges Deployment durchzuführen, führt schnell zu hohen Kosten, die den tatsächlichen Nutzen übersteigen können. Stattdessen sollte überlegt werden, wann ein Feature-Deployment sich wirklich lohnt, um diese gezielt einzusetzen.
Bei Bestandteilen der Anwendung, von denen kein anderer Teil abhängt, spricht kaum etwas gegen den Einsatz von Feature-Deployments. Typische Beispiele sind hier die Einstiegspunkte in die Anwendung, sei es das Frontend oder etwa die öffentliche API.
Genauso lohnen sich Feature-Deployments, bei denen pauschal die vollständige Anwendung bereitgestellt wird, wenn es sich um langlebige und aufwändige Features handelt. Diese Features profitieren oft von ausgiebigem Feedback durch andere Entwickler, Testern aber auch den fachlichen Experten. Zusätzlich tendieren gerade die komplexen Features den Release-Prozess zu blockieren. Je früher grobe Fehler beseitigt werden können, desto eher kann dies verhindert werden.
Werden Feature-Deployments mit Bedacht eingesetzt, können diese enorme Mehrwerte bieten. Eine Überlegung sind sie immer wert – nur nicht zu jedem Preis!
In den kommenden Wochen und Monaten erscheinen weitere Artikel zum Thema Cloud.
Weitere Artikel der Serie
Was ist eigentlich aus Serverless geworden?
Der Artikel ist Teil der IT Spektrum 05/22 S. 48
Die Vorschau des Magazins ist hier zu finden.
Bei der Migration in die Cloud ist vielen Kunden ein Thema besonders wichtig: Feature-Branch-Deployments. Das Ziel ist, einzelne Feature schnell zur fachlichen Abnahme oder zu Testzwecken bereitstellen zu können – ganz losgelöst vom üblichen Release-Prozess und den dazugehörigen Stages.
Wie der Name schon sagt, leitet sich so ein Deployment von der Verwendung von Branches in Werkzeugen wie Git oder Subversion ab. Im Folgenden werden diese vereinfacht als Feature-Deployments bezeichnet.
Traditionell erwies sich die Umsetzung von Feature-Deployments außerhalb der Cloud häufig als eine große Schwierigkeit. Gründe sind meist die fehlenden Hardware-Kapazitäten, aber auch die nicht vorhandene Automatisierung des Deployment-Prozesses. Mit dem Gang in Cloud werden diese Probleme meist gelöst und die Hoffnung kommt auf, dass auch die Umsetzung von Feature-Deployments nur ein weiterer kleiner Schritt ist
Stellt ein Kunde nun also die Frage, ob mit der Cloud denn nun wirklich alles besser wird, ist die pauschale Antwort natürlich erstmal: Ja! – Bei der Erläuterung, was genau zu beachten ist, um erfolgreich Feature-Deployments zu umzusetzen, werden die meisten Kunden jedoch etwas zurückhaltender. Der Teufel steckt auch hier leider wieder im Detail. Je nach Komplexität des Features und des eigentlichen Zwecks des Deployments, ergeben sich durchaus verschiedene Herausforderungen, die es zu meistern gilt.
Auf dem Papier ist die Umsetzung von Feature-Deployments einfach. Die gesamte Anwendung wird inklusive des neuen Features zusätzlich – quasi neben den üblichen Release-Stages – als Deployment bereitgestellt. Entwickler, Tester oder Fachexperten können das Feature so isoliert in einer produktionsnahen Umgebung anschauen, bewerten und fachlich sowie technisch abnehmen.
Für einzelne Features ein gesamtes Deployment durchzuführen, kommt jedoch mit gewissem Aufwand daher. Folgt die Anwendung etwa einer Microservice-basierten Architektur, besteht das Deployment tatsächlich aus einer Reihe von Teil-Deployments, abhängig von der Anzahl der Services. Zusätzlich können weitere Komponenten, wie etwa Datenbanken, das Deployment weiter verkomplizieren. Um ein Feature ausgiebig testen zu können, werden oft auch realistische Daten benötigt. Ein Spiegeln der bestehenden Daten der einzelnen Services in das Feature-Deployment kann daher notwendig sein.
Zudem ist ein vollständiges Deployment mit einem hohen zeitlichen, aber auch finanziellen Aufwand verbunden – je größer die Anwendung, desto größer ist auch dieser Aufwand. Dieser lässt sich häufig nur für die permanenten Release-Stages oder aufwändige, langlebige Features rechtfertigen. Bei kleineren Features übersteigt der Aufwand häufig den tatsächlichen Nutzen.
Um den Aufwand für das Deployment geringer halten zu können, lohnt ein Blick auf das eigentliche Feature. Nicht jedes Feature benötigt ein vollständiges Deployment. Idealerweise reicht auch ein vereinfachtes Teil-Deployment, um das Feature ausgiebig zu testen.
Ein Feature, in dem lediglich die Farbe eines Buttons im Frontend verändert wird, stellt ein gutes Beispiel für ein vergleichsweise einfaches Feature-Deployment dar. Da sich die Änderung lediglich auf das Frontend bezieht, muss auch nur dieses im Deployment enthalten werden. Die Abhängigkeiten des Frontends müssen hier nicht Teil des Deployments sein. Das Frontend kann stattdessen direkt mit dem Backend in den vorhandenen Release-Stages (z.B. der DEV-Stage) kommunizieren (siehe Abbildung 1). Gleichzeitig kann das Deployment so auch von einer bereits gefüllten Datenbank profitieren. Der zeitliche Aufwand sowie die Kosten sind im Vergleich zu einem vollständigen Deployment deutlich geringer.
In einem Feature hingegen, das die API eines Services verändert, ist die Komplexität des Deployments mitunter deutlich höher. Insbesondere, wenn viele Teile der Anwendung abhängig vom veränderten Service sind. Um das neue Feature im Rahmen der Gesamt-Anwendung sinnvoll zu testen, reicht es nicht aus, nur den veränderten Service bereitzustellen. Auch alle Bestandteile, die direkt oder indirekt von diesem abhängen, müssen im Feature-Deployments enthalten sein. Im Zweifel zieht sich dies vom Frontend bis zum veränderten Service (siehe Abbildung 2). Das Deployment kann deutlich weniger von den vorhandenen Release-Stages profitieren. Die Konsequenz sind höhere Kosten und Zeitaufwand beim Deployment.
Neben der Betrachtung der Komplexität lohnt häufig auch ein Blick auf den eigentlichen Grund für ein Feature-Deployment. Woraus ein Deployment bestehen muss, hängt auch davon ab, welches Ziel damit erreicht werden soll.
Der wohl häufigste Grund ist die Vermeidung eines Feature-Staus. So ein Stau kann entstehen, wenn eine Anwendung zunächst eine Reihe von Release-Stages durchlaufen muss, bevor diese dem Benutzer zur Verfügung gestellt wird. Ein Release erreicht erst die nächste Stage, wenn die gesamte Anwendung mit allen Features erwartungsgemäß funktioniert. Diese Abnahme kann etwa durch den Fachbereich, durch Tester oder die Entwickler selbst erfolgen. Verzögert sich die Abnahme oder scheitert diese gar, müssen die entsprechenden Probleme zunächst beseitigt werden. Erst dann kann das Release in die nächste Stage wandern. Hängt das Problem an einigen wenigen Features, werden andere bereits abgenommene Features blockiert und können somit nur verzögert beim Benutzer landen.
Um so einen Feature-Stau zu vermeiden, sollen neue Features frühzeitig und unabhängig vom normalen Release-Prozess abgenommen werden. Ein Feature-Deployment kann hier Abhilfe schaffen. Erst wenn die Abnahme dort erfolgreich war, wird das Feature den regulären Prozess durchlaufen. Die Abnahme in den einzelnen Release-Stages beschränkt sich dann weitestgehend auf die Integration der verschiedenen Features, um so sicherzustellen, dass die Anwendung im Zusammenspiel funktioniert.
Ein weiterer Grund für Feature-Deployment ergibt sich aus dem Entwicklungsprozess. Insbesondere wenn die Anwendung aus verschiedenen Microservices besteht, haben die Entwickler den Bedarf frühzeit ihre Änderungen im Zusammenspiel mit anderen Services zu testen. Dies gilt speziell dann, wenn Features Auswirkungen auf mehrere Services haben. Verändert ein Feature die API eines Services, entsteht mitunter die Notwendigkeit auch Änderungen an anderen Services vorzunehmen.
Durch Feature-Deployments können noch während der Entwicklung Zwischenstände bereitgestellt werden, sodass die Entwickler des abhängigen Service gegen ein reales Deployment entwickeln und testen können. Die Kollaboration zwischen Entwicklern gestaltet sich so deutlich effizienter.
Ein großer Vorteil dieser Art des Deployments ist die geringere Komplexität. Anders als bei der Abnahme eines Features ist es hier nicht notwendig, alle Bestandteile der Anwendung bereitzustellen – besonders indirekte Abhängigkeiten können oft ignoriert werden (siehe Abbildung 3). Auch der Zeit- und Kostenaufwand fällt durch das einfach Deployment geringer aus. Zudem reduziert das frühzeitige Testen der Integration verschiedener Services, mögliche Probleme, die ansonsten erst im Release-Prozess aufgefallen wären.
Die Migration in die Cloud geht oft mit einem erhöhten Automatisierungsgrad und nahezu unbegrenzten Hardware-Kapazitäten einher. Dadurch entstehen viele Möglichkeiten, die es vorher nicht gab. Für viele gehören auch Feature-Deployments dazu. Dennoch sollte der Einsatz wohlüberlegt sein und auch anderen Ansätzen wie Feature-Flags gegenübergestellt werden.
Für jedes einzelne Feature ein vollständiges Deployment durchzuführen, führt schnell zu hohen Kosten, die den tatsächlichen Nutzen übersteigen können. Stattdessen sollte überlegt werden, wann ein Feature-Deployment sich wirklich lohnt, um diese gezielt einzusetzen.
Bei Bestandteilen der Anwendung, von denen kein anderer Teil abhängt, spricht kaum etwas gegen den Einsatz von Feature-Deployments. Typische Beispiele sind hier die Einstiegspunkte in die Anwendung, sei es das Frontend oder etwa die öffentliche API.
Genauso lohnen sich Feature-Deployments, bei denen pauschal die vollständige Anwendung bereitgestellt wird, wenn es sich um langlebige und aufwändige Features handelt. Diese Features profitieren oft von ausgiebigem Feedback durch andere Entwickler, Testern aber auch den fachlichen Experten. Zusätzlich tendieren gerade die komplexen Features den Release-Prozess zu blockieren. Je früher grobe Fehler beseitigt werden können, desto eher kann dies verhindert werden.
Werden Feature-Deployments mit Bedacht eingesetzt, können diese enorme Mehrwerte bieten. Eine Überlegung sind sie immer wert – nur nicht zu jedem Preis!
In den kommenden Wochen und Monaten erscheinen weitere Artikel zum Thema Cloud.
Weitere Artikel der Serie
Was ist eigentlich aus Serverless geworden?
Der Artikel ist Teil der IT Spektrum 05/22 S. 48
Die Vorschau des Magazins ist hier zu finden.
