Mehrfach pro Tag releasen, schneller Feedback vom Kunden erhalten, Time to Market verkürzen – das sind nur ein paar der Vorteile von Continuous Delivery. Mit der Umstellung von Entwicklung und Organisation auf Continuous Delivery haben sich einige bewährte Lösungen im Hinblick auf die Softwarearchitektur ergeben. In den Vordergrund drängen sich immer mehr Schwerpunkte wie entkoppelte, fehlertolerante Systeme und schemafreie Datenbanken. Mit diesem Artikel wollen wir die Vor- und Nachteile dieser architektonischen Entscheidungen auf Continuous Delivery beleuchten.

Continuous Delivery ist ein Vorgehen, dem in den letzten Jahren mehr und mehr Bedeutung zugesprochen wurde. Grundsätzlich beschäftigt es sich mit der Frage, wie Software schneller, sicherer und in regelmäßigeren Abständen produziert werden kann. Als Folge dessen können Auswirkungen einer Änderung oder neuer Funktionalität am Produkt direkt vom Endanwender bewertet werden. Unternehmen wie Facebook, Twitter und Etsy haben ihre Entwicklung dahingehend umgestellt, dass sie Software mehrfach pro Tag releasen können, ohne dass dies negative Auswirkungen hat. Doch wie ist es diesen großen Unternehmen möglich, Projekte mit Hunderten von Entwicklern und komplexen Systemlandschaften in einer solchen Frequenz in Produktion zu bringen? Neben der automatischen Provisionierung von kompletten Umgebungen und dem erhöhten Grad an Testsicherheit, liegt eine der Antworten in den grundsätzlichen Architekturentscheidungen. Die Trennung von Systemen in eigenständige Services, die ein unabhängiges Release ermöglichen, oder die Verwendung von schemafreien Datenbanken, die Schemaänderungen zur Laufzeit unterstützen, sind nur zwei Beispiele. Jede dieser Entscheidungen bringt Vor- und Nachteile mit sich, die man im Rahmen der Entwurfsphase betrachten muss. Dieser Artikel beleuchtet verschiedene architektonische Entscheidungen, die den praktischen Einsatz von Continuous Delivery unterstützen.

Decomposed Systems

Im folgenden Beispiel handelt es sich um das Shopsystem MyShop (fiktiver Name unseres Beispielprodukts). Im Wesentlichen ermöglicht es dem Kunden, sich am System anzumelden, nach Produkten zu suchen und diese zu bestellen. In den ersten Jahren der Entwicklung hat man sich ganz auf den Marktgang konzentriert, weshalb aus der einfachen Shopapplikation ein komplexes System mit mehreren Verantwortlichen und monolithischer Codebase entstanden ist. Die Entwicklung des Systems ist auf mehrere Teams verteilt. Sobald genügend Funktionalität fertiggestellt wurde, kann die Applikation online verfügbar gemacht werden.

Früher oder später kommt der Zeitpunkt, an dem die Teams unterschiedliche Entwicklungsgeschwindigkeiten erreicht haben und z. B. das „Bestellsystem“-Team häufiger releasen möchte, als es den anderen Teams möglich ist. Da die Applikation allerdings als monolithisches System aufgebaut ist, kann diese nur als Gesamtes online gehen.

Wie kann man eine von mehreren Teams aktiv entwickelte Applikation im Sinne von Continuous Delivery releasen? Wie kann das Benutzerverwaltungsteam noch nicht produktionsreife Features in Betrieb bringen, während das Bestellteam einen neuen Stand der Applikation releasen möchte?

Eine Lösung hierfür ist die Aufteilung des Systems in einzelne Komponenten. Statt einer monolithischen Applikation mit gemeinsamer Codebase kann die Applikation in Einzelteile zerschnitten werden. Einen möglichen Schnitt der Komponenten kann man anhand der Business-Domain festmachen. Eric Evans hat in seinem Buch Domain-Driven Design [1] hierfür eine Technik beschrieben, bei der eine Context-Map erstellt wird, welche u. a. Systemgrenzen klar absteckt. Erkenntnisse:

• Wenn möglich, sollten Systeme anhand eines Kriteriums in eigenständige Komponenten zerschnitten werden.

• Eine Aufteilung auf Basis einer Context-Map (s. Domain-Driven Design) in verschiedene Geschäftsbereiche ist sinnvoll.

• Mit der Aufteilung des Systems in eigenständige Komponenten können diese unabhängig voneinander released werden.

Die MyShop-Entwickler haben eine Context-Map erstellt und ihre Applikation anhand ihrer Business-­Domain aufgeteilt. Hierbei wurden vier klare Domains (Bereiche) identifiziert: Benutzerverwaltung, Bestellung, Katalog und Suche.

Die Kommunikation der diesen Bereich entsprechenden Systeme soll nur über REST-Schnittstellen stattfinden. Keiner der Komponenten ist es erlaubt, direkt auf die Datenbanken des anderen zuzugreifen. Des Weiteren haben sich die Teams darauf geeinigt, die Systeme jeden Bereichs als Blackbox zu betrachten, d. h. die Teams stellen sich Schnittstellen zur Verfügung, über die jegliche Kommunikation stattfinden soll. Ein direkter Zugriff, beispielsweise über SQL auf die Datenbank, ist nicht erlaubt.

Abb. 1: Systemschnitt

Das für die Suche zuständige Team stellt die berechtigte Frage nach einem direkten Zugriff auf die Katalog­datenbank, um ein Duplizieren der Artikel zu vermeiden. Diese Veränderung würde viel Zeit und Mühe ersparen.

Durch den direkten Zugriff der Komponente...