Prinzipien von Continuous Delivery für die Anwendungskonfiguration nutzen

Continuous Delivery für Customizing

Carsten Meiser, Andreas Gründer

© Shutterstock.com/Mathias Rosenthal

Das Erstellen von Build-Artefakten und der Durchlauf eines identischen Builds durch die Deployment-Pipeline sind zwei wichtige Punkte beim standardisierten und automatisierten Release einer Anwendung. Neben dem Build-Artefakt existieren im Continuous-Delivery-Prozess noch die Infrastruktur- und die Anwendungskonfiguration. Zur Verwaltung und Bereitstellung der Infrastrukturkonfiguration existieren Techniken wie Infrastructure as Code. Die Anwendungskonfiguration wird jedoch als gegeben dargestellt. Häufig wird diese auf den verschiedenen Umgebungen per Hand erstellt und verwaltet. Mit diesem Artikel wird ein Konzept vorgestellt, das die Verwaltung und Bereitstellung der Anwendungskonfiguration im Continuous-Delivery-Prozess ermöglicht.

Viele Geschäftsmodelle und -prozesse unterliegen einem starken Wandel, die gegenwärtige IT-Industrialisierung und die Fähigkeit zu Veränderungen sind neue Anforderungen, die bestehende IT-Systeme unterstützen müssen. Selbst einst sichere und beständige Geschäftsmodelle, wie das der Taxizentralen und Energieversorger haben sich in den letzten Jahren verändert. Die IT-Industrialisierung übernimmt die Prinzipien der industriellen Fertigung wie Standardisierung und Automatisierung, kontinuierliche Verbesserung, Modularisierung und Konzentration auf die Kernkompetenzen. Doch diese Prinzipien wurden noch nicht überall angewendet.

Bei Geschäftsanwendungen ist ein Teil der Logik über die Konfiguration, auch Customizing genannt, abgebildet. Customizing wird oft stiefmütterlich behandelt, obwohl es eine Anwendung direkt beeinflusst. Den Software-Lifecycle dieser Geschäftsanwendungen betreuen Entwicklung, Betrieb und Fachbereich. Während Entwicklung und Betrieb auf eine Vielzahl an Tools zurückgreifen können, gibt es zur Verwaltung des Customizings oft nur selbstentwickelte Tools oder Skripte, die einzelne Probleme lösen. Diese sind oft sehr technisch und können nicht vom Fachbereich genutzt werden. Dieser ist somit auf den Betrieb angewiesen, wodurch Zeit- und Kommunikationsaufwand entsteht. In den letzten Jahren entstanden Ideen und Konzepte, mit denen es möglich ist, Änderungen beim Betrieb von Anwendungen, z. B. am Quellcode, schneller umzusetzen. Diese Ansätze schreiten erst langsam voran und werden kontinuierlich weiterentwickelt.

Entstehung Continuous Delivery

Continuous Delivery (CD) ist ein solcher Ansatz und im Wesentlichen die Weiterentwicklung von Continuous Integration (CI) und den darum entstandenen Konzepten. CI hat das Ziel, die Produktivität und Qualität von Softwareprojekten zu verbessern. CI betrachtet nach Humble und Farley [S.105–106] hauptsächlich die Entwicklung. Die Entwicklung der Software ist in einem Projekt nur ein Teil des Ganzen. Ein Großteil der Zeit bis zum Release von Software wird für Test und Betrieb beansprucht. Test und Betrieb bringen ihre eigenen Herausforderungen mit sich. Es gibt viele Praktiken, einzelne Probleme im Zusammenhang mit dem Deployment der Anwendung anzugehen, was nicht dazu führen muss, den eigentlichen Flaschenhals zu identifizieren und zu entfernen. Die Lösung hierfür ist, einen ganzheitlichen Ansatz anzuwenden. Continuous Delivery ist ein solcher Ansatz, der CI um Techniken ergänzt, die es erlauben, Software schneller von der Entwicklung in den Betrieb zu überführen. Die Ziele von Continuous Delivery sind nach Humble und Farley, besser geprüfte Releases, ein schnelleres Feedback und eine kürzere Time-to-Market.

Grundlagen von CD

Ein Grundgedanke von CD ist, wie Abbildung 1 zeigt, ein einmal erzeugtes Build-Artefakt durch die Umgebungen zu transportieren. Die Deployment-Pipeline bietet hierfür die Grundlage und ist das zentrale Konzept von Continuous Delivery. Die Deployment-Pipeline beinhaltet i.d.R. die Umgebungen Entwicklung, Test und Produktion und besteht aus mehreren so genannten Stages. Jede Stage repräsentiert einen zu durchlaufenden Schritt mit unterschiedlichem Testzweck im Releasezyklus der Software.

Abb. 1: Continuous Delivery nach Humble und Farley

Abb. 1: Continuous Delivery nach Humble und Farley

Defizit Anwendungskonfiguration

Neben dem Build-Artefakt, das von der Commit Stage erstellt wird (i.d.R. einen CI-Server), zeigt der CD-Prozess in Abbildung 1 auch die Infrastruktur- und Anwendungskonfiguration.

Abb. 2: Softwarekonfigurationsschichten

Abb. 2: Softwarekonfigurationsschichten

Abbildung 2 zeigt die Schichten der Softwarekonfiguration und grenzt die Betriebssystem- und Middlewarekonfiguration, also die Infrastrukturkonfiguration, als technisches Customizing von der Anwendungskonfiguration als fachliches Customizing ab. Im Gegensatz zur Betriebssystem- und Middlewareschicht ist auf der Anwendungsschicht die Verwaltung der Konfigurationen von der Architektur der jeweiligen Anwendung abhängig; dadurch kann Form und Struktur der Anwendungskonfiguration variieren. Das fachliche Customizing besteht aus einem allgemeinen und einem spezifischen Teil. Der allgemeine Teil des fachlichen Customizings ist auf allen Stages gleich, der spezifische Teil unterscheidet sich zwischen den Stages. Eine spezifische Einstellung ist z. B. der Hostname der Stage oder eine E-Mail-Adresse. Der überwiegende Teil des fachlichen Customizings sollte identisch sein, um die Aussagekraft der Testumgebung zu gewährleisten.

Wie bereits erwähnt, gibt es zur Verwaltung und Bereitstellung der Infrastrukturkonfiguration (Betriebsystem- und Middlewarekonfiguration), dem technischen Customizing, Infrastructure-as-Code-Software wie Chef oder Puppet. Damit ist es möglich, Systeme automatisiert zu verwalten und bereitzustellen. Das Infrastructure-as-Code-Paradigma beschreibt ein Vorgehen, das alle Schritte zum Aufsetzen einer Infrastruktur als ausführbaren Code darstellt. Das Erstellen und Konfigurieren von Systemen wird als Programmieren begriffen. Dies funktioniert also dadurch, dass alles streng standardisiert ist und automatisiert durchlaufen werden kann. Die Anwendungskonfiguration ist von Anwendung zu Anwendung unterschiedlich. Es gibt keinen Standard für Anwendungskonfigurationen. Der Grundsatz, dass ein identisches Build-Artefakt alle Stages durchlaufen muss, ist deshalb auf die Anwendungskonfiguration, das fachliche Customizing, nicht so einfach übertragbar. Infrastructure as Code kann für das fachliche Customizing nicht genutzt werden, da der Standardisierungsgrad nicht hoch genug und nur für technisch versierte Benutzer geeignet ist. Die Anwendungskonfiguration sollte aber idealerweise (auch) vom Fachbereich gepflegt werden.

Ein Build-Artefakt durchläuft mehrere Umgebungen mit einer unterschiedlichen, jeweils an die Stage angepassten, nicht standardisierten Anwendungskonfiguration. Diese soll sich nur durch instanzspezifische Einstellungen (wie z. B. Hostnamen, IP-Adressen) unterscheiden. Die Anwendungskonfiguration auf allen Umgebungen nahezu identisch zu halten, wird oft manuell erledigt. Die Aussagekraft des Releasezyklus ist erst gewährleistet, wenn ein identisches Build-Artefakt, eine mit standardisierter Infrastruktur- und Anwendungskonfiguration erstellte Stage durchläuft. Die Verwaltung der Anwendungskonfiguration weist bei vielen Projekten Defizite auf. Zur Art und Weise, wie Anwendungskonfigurationen verwaltet werden müssen, existieren viele Meinungen und Sichtweisen. Daher ist die Frage „Wie verwalte ich die Konfiguration meiner Anwendung in all diesen Umgebungen?“ vielen Beteiligten bekannt. Die technische Bereitstellung der Anwendungskonfiguration ist keine Herausforderung, dies kann z. B. über REST erfolgen. Der Knackpunkt ist die möglichst standardisierte und automatisierte Erstellung einer identischen Anwendungskonfiguration für alle Umgebungen (Entwicklung, Test, Produktion usw.) bis auf instanzspezifische Einstellungen. Dazu werden die Stages beispielsweise von verschiedenen Organisationseinheiten/Rollen betreut (Entwicklung, Betrieb und Fachbereich). Es wird eine einheitliche Lösung benötigt, die von allen Beteiligten bedient werden kann und die es ermöglicht, ohne großen Aufwand die Anwendungskonfiguration für vorhandene Umgebungen zu erstellen und zu verwalten.

Aufmacherbild: Customization concept with hand pressing social icons on blue world map background. von Shutterstock / Urheberrecht: Mathias Rosenthal

Anti-Pattern und Best Practices

Im Folgenden werden einige grundlegende Anti-Pattern und Best Practices vorgestellt. Die Berücksichtigung dieser ist Grundlage für eine funktionierende Continuous Delivery und insbesondere für eine Lösung zur Verwaltung und Bereitstellung von Anwendungskonfigurationen. Die Anti-Patterns und Best Practices sind aus Humble und Farley. Weit verbreitet ist z. B. das Anti-Pattern „Manual Configuration Management of Production Environments“, das das manuelle Konfigurieren der Systeme beschreibt. Änderungen, die von Hand durchgeführt werden, sind oft nicht reproduzierbar und fehleranfällig. „Don’t repeat yourself“ (DRY) lautet die Devise.

Mit der Best Practice „Eliminate Manual Steps“ wird nach Humble und Farley [S. 165] die Bedeutsamkeit von automatisierten Schritten betont. Vorgänge, die automatisiert ausgeführt werden, sind i.d.R. standardisiert und werden geloggt, Fehler sind somit reproduzierbar und letztlich zurückverfolgbar. Humble und Farley betonen, dass es wichtig ist, den gleichen Bereitstellungsmechanismus in der gesamten Systemlandschaft zu unterstützen. Die Best Practice „Deploy the Same Way to Every Environment“ [S. 115] bezieht sich auf den standardisierten Bereitstellungsmechanismus und betont, dass dieser durch häufige Anwendung immer weiterentwickelt wird. Bei abteilungs- und teamübergreifendem Einsatz und Einhaltung des Patterns kann nach Humble und Farley [S. 116] das „it works on my machine“-Syndrom vermieden werden, da der Prozess bis zur Produktionsumgebung mehrere Male ausgeführt wurde.

Bestehende Ansätze sind nicht ausreichend

Es gibt mehrere verbreitete Lösungsansätze, wie das Problem der unterschiedlichen Anwendungskonfigurationen behoben werden könnte. Bei „Environment Detection“ durchläuft die Anwendung Prüfungen und stellt fest, in welcher Umgebung sie deployt ist und lädt die entsprechenden instanzspezifischen Einstellungen. Zuvor muss der Quellcode jedoch um einen Algorithmus erweitert werden, was je nach Anwendung einen hohen Aufwand bedeuten kann. Den Quellcode um umgebungsabhängige (Entwicklung, Test, Produktion usw.) Verzweigungen zu erweitern, ist jedoch keine gute Praktik. Darüber hinaus sollten Änderungen am Quellcode nicht notwendig sein. Nur so kann ein aussagekräftiger Releasezyklus gewährleistet werden und die Anwendung ist fit für Hosting oder Cloud-Umgebungen.

Die Erstellung von Datenbankabzügen(-kopien) bzw. Snapshots vor und nach Änderungen ist weit verbreitet. Die Nachteile davon sind, dass einzelne Änderungen nicht offensichtlich sind und nur mit einem Rollback zum vorigen Snapshot rückgängig gemacht werden können. Mithilfe von Datenbankkopien wird das Customizing von der Produktion in die Testsysteme verteilt. Nach dem Kopieren in das Zielsystem werden verschiedene Einstellungen „entschärft“, d. h. ersetzt oder gelöscht, und an die Testumgebung angepasst. Dieser Schritt wird i.d.R. nur von der Produktivumgebung in die Testumgebung durchgeführt, da ansonsten die Gefahr eines Datenverlusts besteht. Änderungen, die zu einem Fehler geführt haben, können nicht so einfach identifiziert werden und die Anpassung der Produktionsumgebung erfolgt per Hand. Da die Snapshots nur für die Richtung Produktivsystem nach Test oder Entwicklungssystem geeignet sind, werden diese nicht näher betrachtet.

Skripte sind eine schnelle und einfache Art, Automatisierungsmechanismen einzuführen und erfüllen darüber hinaus die Best Practice „Eliminate Manual Steps“. Der Einsatz von Skripten ist weit verbreitet. Die Erstellung und Nutzung ist komplex und wird daher nur von technisch versierten Personen wie Entwicklern und Administratoren genutzt. Skripte sind nur für technisch versierte Benutzer geeignet, aus diesem Grund werden auch sie hier nicht weiter betrachtet. Die dargestellten Lösungsansätze haben zu viele Einschränkungen und reichen somit nicht aus. Eine Lösung sollte die vorgestellten Best Practices wie „Don’t repeat yourself“ (DRY) und Anti-Pattern wie „Manual Configuration Management of Production Environments“ berücksichtigen. Die Umsetzung einer Lösung, die diese berücksichtigt, ist die Grundlage für ein funktionierendes Continuous-Delivery-Konzept.

Neues Konzept: Verwaltung und Bereitstellung von fachlichem Customizing

Die Verwaltung und Bereitstellung der Infrastrukturkonfiguration funktioniert, weil diese standardisiert ist und deshalb automatisiert durchlaufen werden kann. Mithilfe von Chef oder Puppet wird die Infrastrukturkonfiguration kontinuierlich angepasst und verbessert. Dieser standardisierte Bereitstellungsmechanismus über eine Anwendung fehlt bei der Anwendungskonfiguration. Um die Verwaltung und Bereitstellung der Anwendungskonfiguration für mehrere Umgebungen (Entwicklung, Test, Produktion usw.) zu ermöglichen, wird eine separate Anwendung benötigt. Durch eine leichtgewichtige Webanwendung ist die Zusammenarbeit verschiedener Akteure möglich. Die Kernfunktionalitäten wären das Erstellen, Bearbeiten und Verteilen von Customizing. Im Folgenden wird ein solches Konzept vorgestellt.

Der erste Schritt, der zur Einführung einer zentralen Verwaltung und Bereitstellung nötig ist, ist die Standardisierung der Anwendungskonfiguration in einem einheitlichen Datenformat. Hier bietet sich XML an, da es weit verbreitet ist und sowohl einfache als auch komplexe Objekte darstellen kann. Die Bearbeitung sollte auf einer einfachen, aber komfortablen Oberfläche erfolgen. Ein Benutzer sollte nur darüber das Customizing einer Anwendung anfordern und bearbeiten können. Dazu gehört eine Funktion, die es ermöglicht, eine Einstellung als instanzspezifisch deklarieren zu können und die gleichzeitig auffordert, einen Wert für die anderen Stages zu hinterlegen. Anstelle der spezifischen Einstellung in der XML wird z. B. ein Templateausdruck hinterlegt (Listing 1). Hier erfolgt eine Aufteilung des Customizings, d. h. die eigentlichen spezifischen Werte der Einstellungen werden separat gespeichert (Listing 2).

<customizing> 
  <setting id="1">
    <name>hostname</name>
    <value>$ENV.hostname</value>
  </setting>
</customizing>
DEV.hostname = DEV_1
PROD.hostname= PROD_1

Nach Abschluss der Bearbeitung wird das Customizing für die Zielumgebungen erstellt d. h. es entsteht für jede verwaltete Stage eine Customizing-Variante. Ein Customizing, das sich nur durch instanzspezifische Werte zwischen den Umgebungen (Entwicklung, Test, Produktion usw.) unterscheidet, gewährleistet neben der Vergleichbarkeit und Aussagekraft eines durchlaufenen Releasezyklus, eine Minimierung der Fehlerwahrscheinlichkeit. Die einzelnen Teile, aus denen die Customizing-Varianten gebaut werden, können beispielsweise in einem Versionskontrollsystem abgelegt werden. Die erstellten Customizing-Varianten können in einem Repository z. B. mit dem Build-Artefakt gespeichert werden (Abb. 3). Dadurch ist jederzeit ein Rollback zu einer früheren Version möglich. Die Integration in den Continuous-Delivery-Prozess kann über zwei Arten erfolgen (Abb. 3). Die erste Möglichkeit ist die erstellte Customizing-Variante direkt zwischen Anwendung/Stage und Tool zu transportieren, z. B. per REST. Die zweite Möglichkeit ist eine Schnittstelle zu einem Repository. Vom Repository aus könnte dann das Customizing einem CI-Server wie Jenkins zur Verfügung gestellt werden und so z. B. zusammen mit dem Build-Artefakt deployt werden.

Abb. 3: Modifizierter Continuous-Delivery-Prozess

Abb. 3: Modifizierter Continuous-Delivery-Prozess

Die Umsetzung einer Rollenverwaltung bzw. Berücksichtigung von Berechtigungen ist ein weiterer wichtiger Punkt. Die Einführung verschiedener Rollen bietet die Möglichkeit, auf der Oberfläche Einschränkungen umzusetzen. Nicht allen Akteuren soll es beispielsweise möglich sein, Customizing auf die verfügbaren Systeme zu transportieren oder vorhandene Systeme anzulegen bzw. zu löschen. Mit einer Reportfunktionalität können durchgeführte Änderungen am Customizing bzw. Transporte auf die Systeme hinterlegt werden. Dadurch wäre immer ersichtlich, welche Customizing-Version mit welcher Version der Anwendung getestet wurde. Diese Maßnahmen sollen die Einhaltung der Deployment-Pipeline unterstützen. Das hohe Qualitätsniveau, das damit im Umgang mit dem Quellcode erreicht wurde, kann somit auch für Customizing erreicht werden. Das Customizing erlangt eine hohe Bedeutung, denn es wird von nun an weiterentwickelt und als eigenes Artefakt versioniert und getestet.

Fazit und Ausblick

Die Prinzipien der Industrialisierung werden im vorgestellten Konzept aufgegriffen. Die Kernideen wie Standardisierung, Automatisierung und kontinuierliche Verbesserung sind die ersten Prinzipien und auch die wichtigsten. Mithilfe der Standardisierung der Customizing-Daten wird die Grundlage für eine Automatisierung geschaffen. Das Customizing einer oder mehrerer Anwendungen kann somit verwaltet werden. Der Weg ist frei für eine kontinuierliche Verbesserung des eingeführten Bereitstellungsmechanismus. Das Customizing wird jetzt entwickelt und kann wie der Quellcode im Continuous-Delivery-Prozess verwaltet und bereitgestellt werden. Gleichzeitig führt die Einführung einer standardisierten Software zur Ablösung von selbstgebastelten Insellösungen und ermöglicht allen Organisationseinheiten (Entwicklung, Betrieb und Fachbereich) die Nutzung einer einheitlichen Lösung. Durch die Einführung einer einheitlichen Software kann der Zeit- und Kommunikationsaufwand sowie die Fehleranfälligkeit deutlich gesenkt werden. Die verwalteten Anwendungen können beim Erreichen der Fähigkeit zur Veränderung unterstützt werden und sind fit für die IT-Industrialisierung.

Verwandte Themen:

Geschrieben von
Carsten Meiser
Carsten Meiser
Carsten Meiser ist Associate Consultant bei der EXXETA AG in Karlsruhe. Er beschäftigt sich mit Java EE- und Open-Source-Technologien sowie Lösungen im Bereich Continuous Delivery.
Andreas Gründer
Andreas Gründer
Andreas Gründer ist Teamleiter bei der EXXETA AG in Karlsruhe. Er beschäftigt sich seit 2008 mit Java und Open-Source-Technologien im Umfeld der Energiewirtschaft.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: