Christoph Martel | 07.02.2017

Neue Programmkomponenten kontinuierlich ausliefern, agil zusammenarbeiten: Continuous Delivery. Was dabei wichtig ist.

Es ist nicht Eitelkeit, wenn unsere Entwickler ihre Arbeit rasch vorzeigen möchten. Bei allem Stolz auf gelungene Arbeit können erst mit dem Deployment, wenn der fertige Code ausgeliefert, für Kunden sicht- und nutzbar wird, die gemachten Änderungen auch produktiv eingesetzt werden. Erst dann kann unsere Arbeit die Investitionen wieder einspielen.

When the rubber meets the road…

Deployment, Delivery, Auslieferung: Das beschreibt auch aus wirtschaftlicher Sicht einen zentralen Wendepunkt in einem Projekt. Früher stand dieser Punkt oft am Ende eines langen, langen Prozesses der Programmierung; heute liefern wir kontinuierlich und in kleinen Schritten aus – was aber auch bedeutet, gewissermaßen im laufenden Betrieb und mit hochtourig drehenden Reifen den Asphalt zu berühren.

Continuous Delivery fordert einige Umstellung von allen Beteiligten und an mindestens drei Stellen ganz konkrete Transformationen der Arbeitsweise:

  • Automatisierung der technischen Basis
  • Interne Projektstrukturen, die auf die Auslieferung hin ausgerichtet und optimiert sind
  • Veränderte Arbeitsteilung im Team und in der Zusammenarbeit mit dem Kunden
Continuous-Delivery-3-21-torr

Continuous Delivery funktioniert als kontinuierlicher Kreislauf von Tests, Reviews und Feedback, die von unterschiedlichen Personen im Team und beim Kunden kommen und während der Weiterentwicklung wieder in Code umgesetzt werden.

Software-Engineering für das Web: früher und heute

In den Anfängen des Web genügte es, ein paar Dokumente so auf einem Dateiserver abzulegen, dass ein Webserver darauf zugreifen konnte. Die URLs enthielten meist den ganzen Verzeichnispfad und zeigten direkt auf eine Datei, die der Browser anzeigen konnte. Aus dieser Perspektive liegt es nahe, Web-Entwicklung als Dokumentenbearbeitung zu verstehen – und einen Livegang als Upload.

Seither hat sich viel geändert.

Webauftritte bestehen heute nicht mehr aus einer Sammlung von Dokumenten; ihre Inhalte werden in der Regel dynamisch von speziellen Authoring-Systemen generiert (etwa Content Management Systemen), die Inhalte stammen aus einer oder mehreren Datenbanken.

Anpassungen in einem Webauftritt, die nicht nur den Inhalt oder Details im Design betreffen, müssen in aller Regel auf Code-Ebene geschehen. Das liegt auch daran, dass bei einer Webseite heute der „eigentliche“ Inhalt (oder „Content“) oft nur noch ein Zehntel des Quellcodes ausmacht. Der Grund dafür: in den letzten Jahren sind die technischen Möglichkeiten der Browserplattform geradezu explodiert, und dies führt zu entsprechend komplexerem Code.

Websites entstehen bei 21TORR durch die enge Zusammenarbeit von Spezialisten: Informationsarchitekten, Designer, UX-Engineers, Software-Entwickler, Tester, Administratoren und Site-Builder. In letzter Konsequenz ist Web-Entwicklung heute methodische, systematisch geplante Software-Entwicklung – und Continuous Delivery ist die logische Folge der methodischen Weiterentwicklungen.

Auslieferung auf Knopfdruck

Am Ende reicht ein Knopfdruck: Wenn wir den Code vom Produktions- auf den Liveserver spielen, muss der Stand in beiden Umgebungen identisch sein. Dafür müssen wir schon die Code-Basis so aufbereiten, dass sich ein Projekt jederzeit aus einem bitgenau versionierten Entwicklungsstand zuverlässig und wiederholbar aufbauen lässt. Dieser Aufbau oder „Build“ kommt möglichst ohne manuelle Eingriffe aus, lässt sich jederzeit auf „Knopfdruck“ wiederholen und liefert immer identische Resultate.

Continuous-Delivery-2-21-torr

Tools wie Git und Jenkins dienen dazu, über alle Prozessstadien hinweg nicht nur die Übersicht zu behalten, sondern auch korrekt versionierten und kontrollierten Code auszuspielen.

Um einen solchen Projektaufbau zu erreichen, müssen viele Räder ineinandergreifen. Das beginnt damit, dass versionierte Code-Stände ausgespielt werden (also jeweils eine genau beschriebene und nachvollziehbare Version des eigentlichen Codes), nebst Libraries und Frameworks von Drittanbietern. Außerdem werden optimierte Code-Artefakte (z.B. CSS-Dateien) erzeugt, aber auch die System-Konfiguration, notwendige Datenbank-Migrationen, und Suchindizes und vieles mehr werden automatisch durchgeführt und aufbereitet.

Wir verwenden zur Durchführung des Projektaufbaus spezielle Server, auf denen wir mit einer grafischen Oberfläche die Build-Vorgänge überwachen und steuern können.

Schnelles Feedback, automatisierte Tests

Für die kontinuierliche Auslieferung ist es entscheidend, dass wir schnell Rückmeldung über den Status eines Systems bekommen, wenn wir Änderungen eingespielt haben. Wir wollen nicht erst auf dem Live-Server feststellen müssen, dass zum Beispiel eine vermeintlich harmlose Layout-Änderung den Login unmöglich macht. Durch die Komplexität der modernen Webentwicklung sind unerwünschte Nebenwirkungen für einzelne Entwickler eventuell nur schwer abzusehen.

Bei diesen Problemen hilft Automatisierung, wie wir sie bei 21TORR einsetzen. Unsere Build-Server führen bei jeder Änderung des Codes automatisch Tests zur Qualitätssicherung durch. So wollen wir sicherstellen, dass das System bei Auslieferung auch funktioniert.

Die Tests bestehen im Wesentlichen aus drei Gruppen:

  • automatische Tests auf Code-Ebene,
  • vorprogrammierte Tests in „ferngesteuerten“ Browsern und
  • der Mensch als letzte Instanz: Nach dem Vier-Augen-Prinzip prüfen wir jede Webseite manuell und visuell.

Wenn ein Arbeitsstand gründlich getestet wurde, kann er wieder per Knopfdruck auf einen Produktiv-Server ausgeliefert werden. In der Regel ist das eine Prelive- oder Stage-Umgebung, die nicht öffentlich zugänglich ist. In diesen Umgebungen bauen wir zugleich auch den Content für das spätere Livesystem auf.

Sind die Kundentests und der Content-Aufbau abgeschlossen, besteht der eigentliche Livegang, im Idealfall nur im „Umbiegen“ der öffentlichen Aufrufe von der alten Website auf die neue Fassung.

Wir arbeiten fortlaufend und bei jedem Projekt daran, diese Automatisierungsinfrastruktur zu verbessern und auf immer neue Projektanforderungen zu übertragen – denn wir wissen: Geschwindigkeit, Zuverlässigkeit und eben der erhöhte Auslieferungstakt spielen diese anfänglichen Aufwände um ein Vielfaches wieder ein.

Continuous-Delivery-1-21-torr

Auf allen verwendeten Systemen muss das Ergebnis gleich aussehen: Damit Fehler nicht erst bemerkt werden, wenn sie schon live sind.

Deployment first!

Die eigentliche Herausforderung von Continuous Delivery liegt wie so häufig nicht in der Technik, sondern beim Menschen. Sie erfordert einen Kulturwandel, der die bisherige Arbeitsteilung in der Agentur ebenso berührt wie die Projektdurchführung auf Seiten unserer Kunden.

Statt wie früher wochenlang auf einen großen Releasetermin hinzuarbeiten, planen wir heute kleinere, dafür häufigere Deployments ein. Das bedeutet auch, dass wir unserem Kunden schon frühzeitig auch „unfertige“ Versionen des Projekts zeigen. Für unsere Entwickler liegt die Herausforderung darin, dass sie ihre Arbeit zu jedem Zeitpunkt in einem Zustand halten, der ohne größere Aufwände ausgeliefert werden kann.

Dieser Anspruch erfordert viel Disziplin und technische Expertise. „Baustellen“ – unfertige Bestandteile, die z. B. längere Entwicklungszeiten beanspruchen –  müssen im System so abgekapselt werden, dass sie die Auslieferung der schon fertigen Teile nicht behindern oder gar aufhalten.

Letztlich steht dahinter eine ganz neue Herangehensweise: Die Auslieferung, die früher am Ende eines längeren kreativen Prozesses stand, muss heute schon von Anfang an bei der Architektur und in der Umsetzung berücksichtigt werden. Das gilt nicht nur für die initiale Entwicklung, sondern setzt sich folgerichtig auch später in Support und Maintenance fort, die mit dem Livegang ja erst beginnen – auch später durchgeführte Änderungen müssen sich schnell, zuverlässig und jederzeit einspielen lassen.

Sprint mit kleinen Schritten

Unsere Kunden profitieren am besten von einer kontinuierlichen Auslieferung, wenn sie mit uns in einem agilen Projekt-Setup zusammenarbeiten. Das bedeutet, dass wir den Projektablauf in Iterationen – sogenannte „Sprints“ – unterteilen, an deren Ende idealerweise jeweils ein Teilergebnis steht, das bereits ausgeliefert werden kann.

Diese Vorgehensweise erfordert gründliche Planung und Vorbereitung auf Seiten des Projektmanagements. Auch hier ist tiefgreifende technische Expertise gefragt, denn die angestrebten Komponenten sollten unabhängig voneinander angelegt sein, damit sie auch eigenständig getestet und ausgeliefert werden können. Wenn sie dann noch agil so geplant und priorisiert sind, dass sie jeweils einzeln für sich einen direkten Mehrwert schaffen, dann erfüllt die Continuous Delivery ihr Versprechen, dass solche Projekte für den Kunden schneller wirken und sich besser rechnen.

Transparente und effiziente Teillieferungen statt „Big-Bang-Release“: Continuous Delivery ist für uns gelebte digitale Transformation. Wir bauen neue Technologien, Skills und Prozesse auf, um für unsere Kunden das Beste aus dem modernen Web herauszuholen, schnell und zuverlässig.

Christoph Martel
Christoph Martel | 07.02.2017
0 Comments

Leave a comment

Keine Angst, deine E-Mail-Adresse wird nicht veröffentlicht.
Die erforderlichen Felder sind mit * markiert.