© 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 leistungsstarken IDEs wie Eclipse und IntelliJ. Und um besser testen zu können, kamen Tools wie Mockito und Selenium. Nur eine Sache blieb zurück: das Deployment in die Produktion. Bis heute.

Continuous Delivery

Continuous Delivery fängt an, wo Continuous Integration aufhört. Es ist die nächste Stufe auf dem Weg zum schnellen Feedback. Nun wird die Software nicht nur kontinuierlich gebaut und getestet, sondern auch geliefert. Feedback kommt nicht nur von der Maschine, wie bei Continuous Integration, sondern auch vom Menschen. Jetzt ist der Benutzer dran. Zusammen mit den Prinzipien aus Lean Startup wird der Rückmeldekreis geschlossen (Abb. 2.1). Der Fachbereich hat nun über Entwicklung und Betrieb die Möglichkeit, schnell das Feedback der Benutzer einzuholen. Ideen werden früher validiert, Richtungen werden früher korrigiert, Probleme werden schneller behoben. Darwin schaut zu: Einige Unternehmen werden profitieren, einige verschwinden.

Abb.2_1.png

Abbildung 2.1: Geschlossener Rückmeldekreis

Herausforderungen

Der Gedanke, schneller zu liefern, ist da entstanden, wo der Marktdruck am höchsten ist: Internetunternehmen. Die rasante Evolution erlaubt einfach keine Pause. Sowohl der Benutzer als auch die Konkurrenz schlafen nicht. Man muss am Ball bleiben, um seine Position zu behalten. Für Portale wie Facebook, Etsy und Flickr ist Continuous Delivery das tägliche Brot. Oder besser gesagt, halb- oder viertelstündliches Brot. Mittlerweile wagen sich auch immer mehr Unternehmen im deutschsprachigen Raum an diesen Schritt. Diese Umstellung bringt aber Herausforderungen mit sich und erfordert ein Umdenken.

Wie beherrschen wir das Risiko, so häufig live zu gehen? Was brauchen wir, um im Stundentakt kleine Änderungen und Korrekturen ausliefern zu können? Wie schaffen wir Vertrauen und Zuverlässigkeit? Was müssen wir beim Bauen von Releases beachten? Wie deployen wir effektiv? Und wie minimieren wir die Unterschiede zwischen Umgebungen, um möglichst hohe Erfolgschancen zu garantieren? Wie gehen wir mit der Anwendungskonfiguration um? Und was ist überhaupt mit den Datenbanken? Wie bleiben wir lieferfähig? Und wie minimieren wir den Impact auf die Endbenutzer? Und letztendlich, was müssen wir im Problemfall tun?

Einige dieser Fragen lassen sich nur organisatorisch lösen, zum Beispiel durch engeres Zusammenarbeiten traditionell getrennter Organisationseinheiten wie Entwicklung und Betrieb. Vieles kann man aber mit geschickten Prozessen und Architekturentscheidungen weitgehend bewältigen. Im Folgenden schauen wir uns an, wie das geht.

Voraussetzungen

Es gibt zwei große Voraussetzungen für Continuous Delivery. Als Erstes benötigen wir einen modernen agilen Entwicklungsprozess wie Scrum oder Kanban. Fachbereich und Entwicklung müssen eng zusammenarbeiten. Man muss sich gegenseitig vertrauen und zusammen an einem Strang ziehen. Die Entwicklung muss dem Fachbereich eine richtige und logische Priorisierung, sowie ein aktives Mitdenken und Problemberücksichtigung zutrauen. Der Fachbereich muss der Entwicklung einen kooperativen lösungsorientierten Ansatz in Kombination mit einer konstant hohen Lieferqualität zutrauen.

Und das bringt uns zur zweiten Voraussetzung: ein solides Vertrauen in die Software durch ein solides Continuous-Integration-Verfahren. Unsere Anwendung muss nach jedem Commit vollautomatisiert gebaut, getestet und paketiert werden. Die Tests laufen auf drei Ebenen: Small (Unit Tests), Medium (Integrationstests) und Large (Black-Box-Systemtests). Sie sind grün und decken die wichtigsten Use Cases so ab, dass man genügend Vertrauen in die volle Funktionsfähigkeit des Systems hat. Werden im Produktivbetrieb dennoch Fehler entdeckt, werden die Tests so erweitert, dass ein weiteres Auftreten ausgeschlossen wird. Wenn diese Voraussetzungen erfüllt sind, ist es so weit: Der Weg zu Continuous Delivery ist frei (Abb. 2.2).

Abb.2_2.png

Abbildung 2.2: Continuous-Integration-Verfahren auf drei Ebenen

Releases

Ein Release ist ein fest definierter und paketierter Zustand unserer Software. Dieser Zustand wird mit einer Versionsnummer versehen, um ihn eindeutig identifizieren zu können. Das bietet gleich mehrere Vorteile. Man kann eindeutig fes...

Neugierig geworden? Wir haben diese Angebote für dich:

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