© DrHitch/Shutterstock.com
Agilität und Continuous Delivery

3 CD in der Praxis


Vor- und Nachteile

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. In diesem Kapitel 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 Außenwirkungen 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. Dieses Kapitel 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 Code-Base entstanden ist. Die Entwicklung des Systems ist auf mehrere Teams vert...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang