Was ist eigentlich Continuous Delivery?

Der Begriff beschreibt eine Sammlung von Techniken, Prozessen und Werkzeugen, mit deren Hilfe kurze Entwicklungszyklen und die schnelle Auslieferung von Software-Updates oder produktiven Endsystemen ermöglicht werden.

Die Idee hinter dem Begriff Continuous Delivery lässt sich am besten mit einer auf Knopfdruck abrufbaren Software vergleichen. Wenn der Kunde eine aktuelle Version seiner Software wünscht, muss er diese nur anfordern.

Bei klassischen Entwicklungssystemen bzw. -ansätzen war und ist das nicht möglich. Die Software wurde zunächst programmiert, dann getestet und evaluiert und weiteren Überarbeitungen und Prüfungen unterzogen, ehe sie beim Kunden ankam.

Continuous Delivery verändert dieses System und sorgt durch die kontinuierliche Überprüfung aller Änderungen und durch die automatisierten Tests für eine jederzeit lauffähige Software. Der Kunde kann somit tatsächlich in beinahe jedem Entwicklungsstand der Software die aktuelle lauffähige Version anfordern und erhält ein überprüftes und getestetes System ohne Fehler. Somit lassen sich die Prozesse deutlich beschleunigen und verschlanken, was vor allem wirtschaftliche Vorteile mit sich bringt.

Von der Idee bis zum Kunden mittels Continuous Delivery

Der Prozess der Continuous Delivery wurde erstmals im Jahr 2006 in einem Vortrag von Jez Humble, Chris Read und Dan North erwähnt. Humble und David Farley haben das Thema deutlich vertieft in ihrem Buch „Continuous Delivery“ aus dem Jahr 2010. Ziel war und ist es, von der anfänglichen Idee bis zum Endprodukt eine möglichst kurze und variable Kette zu schaffen, die dank andauernder Überprüfungen enorm belastbar ist.

Die in der ursprünglichen Wahrnehmung aufeinanderfolgenden Prozesse von Entwicklung, Qualitätskontrolle und Auslieferung werden nicht mehr als große Einheiten verstanden, sondern als miteinander verzahnte Kleinsteinheiten mit entsprechend geringem Lastaufwand. Somit ist es möglich, Entwicklungsschritte zu beschleunigen und neue Funktionen schneller zu implementieren.

 

Radikale Automatisierung für umfassende Software-Standards

Das große Problem bei der Software-Entwicklung liegt vor allem in den umfassenden Tests, welche jede Software vor der Freigabe durchlaufen muss. Diese führen, vor allem bei umfangreichen Tests, häufig zu Stopp-Phasen in der Entwicklung und sind somit mit dem Begriff der Continuous Delivery nicht zu vereinbaren.

Auf der anderen Seite können die Tests aber auch nicht ausgelassen werden, da eine Kompatibilität und Lauffähigkeit der entwickelten Software gewährleistet werden muss. Dieses Problem umgeht die Continuous Delivery durch die Implementierung von automatisierten Testsystemen in kleinsten Schritten.

Bei Änderungen oder Erweiterungen an der Software werden diese Anpassungen sofort und automatisiert getestet und überprüft. Somit entsteht eine Kette der Qualitätssicherung, welche bei Fehlern und Schwierigkeiten sofort die Ursache der Fehler aufzeigen kann. Aufgrund der kleinen Entwicklungsschritte zwischen jedem Testverfahren sind die Änderungen einfach zu identifizieren, was die Fehlersuche minimiert.

Automatische und manuelle Tests und Freigabeschritte

Im Rahmen der Continuous Delivery wird versucht sowohl funktionale als auch nicht funktionale Anforderungen an die entwickelte Software mittels unterschiedlicher Testtypen mit einem sehr hohen Grad an Automatisierung zu validieren. Die Tests werden hierbei in mehreren Stufen organisiert und nacheinander für jeden aktuellen Stand der Software durchgeführt.

Was ist eigentlich Extreme Programming (XP)?

Der Begriff „Extreme Programming (XP)“ beschreibt im Wesentlichen die Art und Weise, wie unter Anwendung Agiler Prozesse, Software programmiert wird. Dabei stehen kurze Entwicklungszyklen und schnelle Reaktionszeiten auf neue oder sich ändernde Anforderungen im Vordergrund.

Extreme Programming (XP) ist eine seit einigen Jahren immer populärer werdende Methode zur Entwicklung von Software in kleineren Teams. Die teilweise radikalen Änderungen im Vergleich zur „traditionellen“ Vorgehensweisen erfordern umfangreiches Umdenken in technischen und sozialen Prozessen, bieten aber die Möglichkeit der Beherrschung zuvor schwer zu bändigender Dynamiken.

Als Vater des Extreme Programming gilt der amerikanische Software-Ingenieur Kent Beck. Seine „Feuertaufe“ bestand XP in den Jahren 1997-1998 bei der programmtechnischen Umsetzung des Daimler-Chrysler „Project C“ – Chrysler Consolidated Compensation.

Das interne Softwareprogramm für eine neue Mitarbeiter-Gehaltsabrechnung war in eine kritische Sackgasse geraten. Eine vom Autobauer engagierte Software-Entwicklungsgruppe um Kent Beck setzte das Projekt, basierend auf der Methode „Extreme Programming“ neu auf. Der neue Weg war von Erfolg gekrönt.

Beck fasste die in diesem Projekt gesammelten Erfahrungen in seinem Buch „Extreme Programming Explained“ zusammen. Als Gerüst für die Rahmenbedingungen der Extremprogrammierung bezeichnet der Autor darin die drei Hauptbestandteile

  • Werte (Values),
  • Prinzipien (Principles) und
  • Techniken (Practices).

 

Charakteristisch: zyklische Vorgehensweise

Charakteristisch beim Extreme Programming ist die zyklische Verfahrensweise auf den Entwicklungsprojekt-Ebenen. Diese Struktur betrifft die eigentliche Programmierung. Sie wirkt aber auch prägend auf die obligatorische Abstimmung im Entwicklungsprojekt-Team.

Diesem Zyklus unterliegt letztlich auch das gemeinsam mit dem Kunden definierte Anforderungsmanagement. Spätestens an dieser Stelle wird deutlich, dass XP auf einen vom Kunden strikt vorgegebenen Projekt-Anforderungskatalog bewusst verzichtet.

An seine Stelle tritt das sogenannte „Agile Modeling“. Es ermöglicht die Berücksichtigung von Kundenwünschen im Laufe der voranschreitenden Software-Entwicklung. So entstehen Entwicklungszyklen in Einheiten von einem Tag bis zu einer Woche. Sämtliche Themeninhalte einer komplexen Programmentwicklung, zum Beispiel

  • Analyse der Anforderungen
  • Produkt Design
  • Implementierung
  • Testphasen und Testtiefe

werden in diesen kurzen Zyklen aktualisiert und in den weiteren Entwicklungsprozess implementiert.

Diese zeitnahe und problemorientierte Verfahrensweise trägt der Erkenntnis Rechnung, dass Kunden und Auftraggeber die tatsächlichen Anforderungen und Leistungsprofile bei Projektbeginn oft nicht im Detail kennen. Die Erfahrung bei der klassischen Projektvorgabe zeigt auf, wie Pflichtenhefte häufig mit entbehrlichen Features belastet werden, während essentielle Funktionen vergessen werden.

 

Vorteile von XP bei komplexen Entwicklungsprojekten

Die Vorteile von Extreme Programming entfalten insbesondere bei komplexen Software-Entwicklungsprojekten ihre problemorientierte Wirkung. An die Stelle einer komplexen, starren Projektvorgabe tritt die in kürzere Iterationszyklen unterteilte Vorgehensweise.

Auf diesem Wege wird die Software-Entwicklung vereinfacht, was die aktive Einbindung der Kunden und Auftraggeber in das Projekt ermöglicht. Insbesondere diese Möglichkeit der Kommunikation mit dem Kunden gibt den nächsten Programm-Entwicklungsschritten eine konkrete Richtung. Kundenwünsche lassen sich zeitnah korrigieren, revidieren oder ergänzend konkretisieren.

Ängste, mangelnde Offenheit und Kommunikation sowohl auf Seiten des Auftraggebers als auch der Entwickler sind häufig bereits der Anfang vom Ende jeder erfolgreichen Softwareentwicklung. Extreme Programming begegnet diesen Problemen durch kooperative Entwicklungsmodelle (Pair Programming), iterative Verfeinerungen der Aufgabenstellung und Konzentration auf schnelle Releasesyklen und Testbarkeit von Systemen.

Die Software-Entwicklung lässt sich dank dieser zyklischen Vorgehensweise signifikant beschleunigen. Auch der mit dem reduzierten Zeitaufwand gekoppelte Kostenaspekt birgt Einsparpotenziale. Im günstigsten Falle bewirkt das Zusammenspiel erfahrener Programmierer in Verbindung mit aktiv eingebundenen Kunden Projektvorteile, die sich mit Hilfe des Extreme Programming in Form eines qualitativ hochwertigen, passgenauen Software-Programms darstellen.

Bedrohte Freiheit – Wie weit liefern wir uns Computern aus?

Die Automatisierung bedroht die Freiheit, sagen Wissenschaftler – und fordern einen Kodex für Maschinen. Müssen wir uns als Menschen neu definieren? Sind wir autonom oder heteronom?

„Entschuldigen Sie bitte, wo ist denn hier die Liste der Dinge, die nicht automatisiert werden sollen?“ Das ist die erste Frage, die der Zukunftsforscher Alexander Mankowsky den Verantwortlichen eines Automatisierungsprojektes jeder Art stellt – sei das ein autonomes Auto oder eine ganze Smart City. „Die schauen dann meistens ganz verblüfft“, sagt Mankowsky und grinst.

Für einen gelernten Philosophen wie ihn ist diese Frage alles andere als abwegig. Denn für ihn liegt darin der Indikator, inwiefern die menschliche Freiheit mitgedacht wird. Soziale Wahrnehmung lasse sich nicht automatisieren, erst recht nicht die Freiheit zur Willkür, zu spontanen Handlungen, die eine Maschine nicht vorhersehen kann.

Die wachsende Automatisierung wird von der breiten Öffentlichkeit gerade erst wahrgenommen – und gern bewundert. Doch die ersten Wissenschaftler warnen davor, die Technik den künftigen Status quo unseres Zusammenlebens bestimmen zu lassen. „Wir haben das Recht, nicht berechenbar gemacht zu werden“, sagt auch Frieder Nake, Professor für Informatik der Universität Bremen. Nake gilt als ein Pionier der Computerwissenschaft, als Mathematiker hat er Anfang der sechziger Jahre die ersten Rechner programmiert und schließlich die Informatik mitgegründet. Wohin sein Fach inzwischen geht, stimmt ihn nachdenklich. „Die Mathematik weiß, dass es harte Grenzen der Automatisierung gibt“, sagt er: alles, was berechnet werden kann. Emotionen gehören nicht dazu, „eigentlich alles, was das Leben ausmacht“. Wenn Menschen Maschinen bauen, die so tun, als hätten sie Gefühle, findet er das falsch.

Aus Sicht des Zukunftsforschers Mankowsky stehen wir gerade an einer entscheidenden Schwelle: Wir müssen uns als Menschen neu definieren. Sind wir autonom oder heteronom? „Wir sind handlungswirksam fremdbestimmt“, sagt er, beispielsweise, wenn wir wie ferngesteuert den Anweisungen unseres Navis folgten. Die Führungskräfte bei Daimler, für die Mankowsky arbeitet, werden gefordert von ihrem Philosophen, der sie manchmal zusammentrommelt, um grundlegende Fragen zu klären: „Wer nur auf die Technologie schaut, hat nicht verstanden, wie sehr sich die Gesellschaft verändern wird.“

Mit dieser Sichtweise ist Mankowsky nicht allein. „Wir brauchen einen digitalen Kodex“, fordert Matthias Kammer, der Direktor des Deutschen Instituts für Vertrauen und Sicherheit im Internet (DIVSI). Von der Deutschen Post AG als unabhängige Forschungsstelle finanziert, diskutiert das Institut mit Vertretern aus Wissenschaft, Wirtschaft und Gesellschaft, inwiefern ein solcher Kodex die Lücke füllen könnte, die Gesetze in der digitalen Welt hinterlassen. Allein die Debatte um das EU-Datenschutzrecht zeige, dass Gesetze nicht alles regeln können. Kammer: „So ein Kodex fällt nicht vom Himmel, wir müssen ihn uns erarbeiten wie einen neuen Gesellschaftsvertrag.“ Den Vergleich mit der Französischen Revolution findet er gerechtfertigt: „In der Phase, in der wir jetzt leben, stehen viele seit 1945 stabil gewordenen Selbstverständlichkeiten in Frage.“

Den Forschern geht es jedoch auf keinen Fall um Technologie-Verweigerung: Kammer kritisiert etwa, dass beim Wort „Big Data“ in Deutschland vor allem an die Risiken gedacht wird, nicht aber an die darin steckenden Chancen. Mankowsky ist ebenfalls überzeugt, dass uns das Datensammeln an sich nutzt: „Wir erfahren viel über uns selbst, wir brauchen diese Daten.“ Nur: Vertrauen sei der falsche Begriff, kritisiert er den DIVSI-Ansatz. Es bedürfe vielmehr der Fairness und der Transparenz, damit jeder die Freiheit habe, selbst zu entscheiden, welche Daten er von sich preisgibt.

Der gegenwärtige rechtliche Datenschutz, der in solchen Fragen die „informierte Einwilligung“ der Nutzer voraussetzt, sei allerdings wenig geeignet, diese Freiheit zu verteidigen, sagt der Rechtsinformatiker Nikolaus Forgó von der Universität Hannover: Das deutsche Datenschutzrecht stamme aus der Zeit der Volkszählung Anfang der 80er Jahre und habe seit Anbeginn einen zentralen Fehler – es definiere nicht in der notwendigen Genauigkeit den Begriff „personenbezogene Daten“. Gehören dazu auch die Geodaten, also Angaben, wo sich eine Person aufgehalten hat oder aufhält? Und wie fein darf die Auflösung von Satellitendaten sein, bis sie personenbezogen werden?

Auch die so genannte informierte Einwilligung ist heutzutage zur Fiktion geworden: Wer alle Bedingungen lesen wollte, denen er als Internetnutzer zustimmen müsste, braucht dafür 76 Tage im Jahr. Eine Internetseite ließ kürzlich tausende Nutzer bestätigen, dass sie mit der Anmeldung ihre Seele verkauften – ein gelungener Aprilscherz, eigentlich. Nur bemerkte ihn keiner. Alle verkauften ihre Seele.

Marc Langheinrich, Professor für Informatik an der Università della Svizzera Italiana in Lugano, sieht eine große Datengläubigkeit gegeben. Dabei hätten Daten an sich keine Aussagekraft. Im Gegenteil, häufig würden aus großen Datenmengen falsche Schlüsse gezogen. Und das kann durchaus zum Nachteil derer geschehen, deren Daten gesammelt wurden – weshalb Langheinrich das Argument verheerend findet, dass sich diejenigen, die nichts zu verbergen haben, auch keine Sorgen machen müssten. Denn die Auswahl der Daten beeinflusse das Ergebnis eines Rechenprozesses ebenso wie ihre Interpretation.

Frieder Nake aus Bremen pflichtet ihm bei: „Ein Modell kann nur das ergeben, was in das Modell eingeflossen ist.“ Was im Umkehrschluss bedeutet: Wer ein bestimmtes Resultat erhalten möchte, kann entsprechend manipulieren, indem er die Auswahl der Daten und deren Gewichtung bestimmt. Für die Betroffenen ist das am Ende meist kaum verstehbar, da die Entscheidungen von Algorithmen häufig nicht einmal vom Entwickler selbst nachvollzogen werden können. Deshalb könne für derartige Fälle ein gesellschaftlicher Kodex durchaus nützlich sein.

Einen Kodex gibt es bereits, nämlich den „Code of Ethics“ der Association for Computing Machinery. Nur ist dieser mit Grundsätzen wie „Vermeide Schaden an anderen“ oder „Respektiere die Privatsphäre“ sehr allgemein gehalten. „Man sagt den Entwicklern: Privatsphäre ist wichtig. Aber sie haben keine Ahnung, was das genau bedeutet“, sagt Sarah Spiekermann, Professorin für Informationssysteme an der Wirtschaftsuniversität Wien. „Wenn sich Maschinen in unser Leben so einflechten, wie sie es jetzt tun, müssen wir über einen konkreteren Kodex nachdenken.“ Andernfalls sieht sie grundlegende menschliche Bedürfnisse in Gefahr – angefangen bei Freiheit und Gesundheit.

Wenn der Algorithmus falsche Zahlen liefert

Spiekermann erklärt das am Beispiel eines ihr bekannten Finanzmanagers. Das EDV-System seines Unternehmens spuckt Zahlen aus, die er für falsch hält. Aber niemand im Unternehmen kann ihm sagen, wie diese zustande kommen. Ein Algorithmus hat sie errechnet, der damalige Programmierer ist nicht mehr im Haus, es gibt keine Dokumentation. Der Manager ist für Zahlen verantwortlich, deren Herkunft er nicht kennt und die er anzweifelt. Aber er ist machtlos. „Diese Situation herrscht heute in deutschen Unternehmen“, sagt Spiekermann.

Deshalb hält sie auch Rückkopplungsprozesse für ein großes Thema: Wie kommunizieren wir mit den Maschinen und diese mit uns? „Feedback über das System ist ein Effekt der Kontrolle, die der Mensch über die Maschine hat“, sagt Spiekermann. Auch Zukunftsforscher Mankowsky hat in seinen Experimenten nachgewiesen, dass Kommunikation ein Schlüssel dazu ist, dass die Anwesenheit intelligenter Maschinen als angenehm empfunden wird. Beispielsweise sollten autonom fahrende Autos den Menschen am Straßenrand übers Lichtsignale mitteilen, dass es sie wahrgenommen hat – und wo es hinfahren will.

Für die Software-Entwickler bedeutet das ein Umdenken. Anstatt einfach mal einen Prototyp zu programmieren und den so nach und nach weiter zu entwickeln, muss am Anfang die Frage stehen: Welche Werte sollen in das System eingearbeitet werden? „Das ist aufwendig“, sagt Spiekermann, „dafür muss die Software-Entwicklung von einer Kindergartenspielwiese zu einer echten Ingenieursdisziplin werden, in der man Regeln einhält.“ Solche Systeme werden dann sehr viel teurer sein als heute. Aber dafür besser.