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

2 Architecting for Continuous Delivery


… with Zero Downtime. Prinzipien und Techniken

Continuous Delivery ist heute überall. Das Thema boomt. Fast jeden Tag erscheinen neue Blogeinträge mit Erfolgsmeldungen. Und auf Softwarekonferenzen kommt man schon längst nicht mehr an dem Thema vorbei. Immer mehr Firmen berichten, dass sie es erfolgreich einsetzen. Oft aber bleibt die Diskussion oberflächlich. In diesem zweiten Kapitel werden wir die Oberfläche verlassen und in die Tiefe gehen. Wir werden uns eine Reihe von Techniken anschauen, die es ermöglichen, eine Softwarearchitektur so aufzubauen, dass sie das Versprechen von Continuous Delivery Realität werden lässt. Sagen Sie „Auf Wiedersehen“ zu vierteljährlichen Releases. Bitte anschnallen! Hier kommt die Rettung!

Alles, was hier präsentiert wird, ist praxiserprobt. Die Beispiele in diesem Kapitel werden mit Java-Web-Apps, SQL-Datenbanken, Git, Maven und Jenkins illustriert, da diese Tools zurzeit ihre jeweiligen Märkte dominieren. Die Konzepte sind aber völlig unabhängig von Sprache und Tool.

Ein kurzer Blick zurück

Continuous Delivery kommt nicht aus dem Nichts. Es ist ein weiterer logischer Schritt auf dem langen Weg der Professionalisierung unserer Industrie. Um besser zu verstehen, wo die Reise hingeht, springen wir kurz in die Zeit zurück und schauen uns an, aus welch düsteren Zeiten wir kommen.

Das moderne Zeitalter der Softwareindustrie hat ungefähr Mitte der Neunziger angefangen. Es war die Zeit, in der das Design-Patterns-Buch der Gang of Four gerade erschienen war, Mobiltelefone und das Internet noch als exotisch galten, C++ die dominante Sprache war und Java noch hauptsächlich für Applets verwendet wurde. Wasserfall war als Vorgehensmodell die Norm, Entwickler testeten nur manuell (wenn überhaupt) und make war das feinste Werkzeug, um Software zu bauen.

Als Kent Beck und Erich Gamma die erste Version von JUnit veröffentlichten, fiel es allen wie Schuppen von den Augen: Unsere Industrie muss effizienter werden! Und der einzige Weg dorthin sind kürzere Feedbackzyklen. Was mit Unit Testing anfing, verbreitete sich schnell auf weitere Aktivitäten. Erst kam XP, dann Refactoring und in 2001 das Agile Manifest. Das Momentum war nicht aufzuhalten. Mit dem Internet wurde alles komplexer, schneller und integrierter. Evolution war ein Muss. Und an mehr Effizienz führte kein Weg vorbei. Für die Zusammenarbeit mit dem Fachbereich wurde aus Wasserfall Scrum and Kanban. Make wurde zu Ant, Maven oder Gradle. Einfache Texteditoren wurden zu leistungss...

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