Die Time-To-Market liegt zwischen zwei Tassen Kaffee

Aber wie lässt sich eine so kurze Time-To-Market umsetzen? Wie kann eine Idee vom Vormittag bereits am Nachmittag den ersten Testkunden erreichen? Oder wie kann ich einen Bug im Produktionssystem vielleicht sogar innerhalb wenigen Minuten schließen?

Die Voraussetzung dafür besteht aus drei wesentlichen Bestandteilen:

• hohe Automatisierung
• Cross-Functional Teams und
• eine Philosophie des Lernens.

Ein schneller Rollout funktioniert nur dann, wenn möglichst wenig manuelle Eingriffe nötig sind.

Continuous Integration und Continuous Delivery

Ein erster Schritt in diese Richtung ist Softwareentwicklung auf Basis von Continuous Integration (CI): Dabei werden der Quellcode eingecheckt und automatisiert gebaut, Codemetriken zur Bestimmung der Qualität ermittelt sowie automatisierte Unit-Test ausgeführt.

Eine zweite Ausbaustufe ist dann das automatische Rollout, also Continuous Delivery (CD). Der gebaute Quellcode wird dabei automatisiert auf die Zielumgebungen gebracht.

Testautomatisierung

Die Automatisierung von Tests ist das oberste Gebot der Stunde: Manuelle Integrationstests durch Klicken auf Oberflächen erfolgen nicht mehr. Die Rolle des klassischen Testers verschiebt sich also mehr zum Testsoftwareentwickler bzw. Test-Scripter.

Selbst bei kleinen Projekten ist es ratsam, direkt mit der Testautomatisierung zu beginnen: Einerseits zur Vermeidung manueller Schritte, andererseits werden kleine Projekte oft größer als gedacht – und der spätere Aufbau einer Testautomatisierung kann teuer werden.

Multi-Environment Deployment

Die CD-Pipeline kann sich über mehrere Umgebungen erstrecken. Nach dem Codechecking und dem erfolgreichen Build, erfolgt die Auslieferung auf eine Testumgebung. Dort führt die CD-Pipeline dann automatisierte Integrationstests durch. Treten dabei keine Probleme auf, wird der Rollout direkt auf Produktion durchgeführt – idealerweise ohne menschliche Interaktion.

Konzepte wie Canary Deployment helfen dabei, neuen Code in Produktion erst einem kleinen Anteil an Usern zur Verfügung zu stellen. Funktioniert das neue Feature, wird es nach und nach weiteren Benutzern zur Verfügung gestellt.

Business + Development + Operation = BizDevOps

Eine Grundidee von DevOps ist, dass Entwickler (Devs) und Betriebsmitarbeiter (Ops) ein gemeinsames Team bilden und dadurch auf die Probleme des jeweiligen Arbeitsbereichs direkt von Beginn an eingehen können. Bspw. stellt der Betrieb hohe Anforderungen an Monitoring und Logging einer Anwendung. In enger Abstimmung können diese durch die Entwickler direkt berücksichtigen werden. Auch kennen die Operations-Spezialisten die typischen Skalierungsproblemen, die Einfluss auf die Anwendungsarchitektur haben sollten.

Für fachliche Entscheidungen bringen der Kunde oder Product Owner (Biz), Ihre Expertise in das Team ein. Gerne vergessen, aber ebenso wichtig, sind Tester und Sicherheitsexperten.

End-2-End-Verantwortung

Dieses Team bearbeitet nun völlig autark einen thematischen Bereich. Bspw. entwickelt es einen entkoppelten Microservice und ist jederzeit in der Lage, eine neue Version auszurollen, Test und Betrieb zu gewährleisten, sowie die Entwicklung auf Basis der Kundenbedarfe voranzutreiben.

Jeder Mitarbeiter im Team besitzt dabei weiterhin seine Kernkompetenz. Es geht nicht darum, dass die Entwickler zukünftig den Betrieb übernehmen. Auch wenn die Teamstruktur automatisch für ein besseres Verständnis der bisher fremden Aufgabenbereich führt. Vielmehr sorgt BizDevOps dafür, dass die interdisziplinäre Zusammenarbeit und Kommunikation verbessert wird.

Damit geht auch eine neue Freiheit einher: Das Team kann sich selbst organisieren und den besten Weg für Implementierung und Betrieb wählen.

Gleichzeitig wächst die Verantwortung: Das Team ist End-2-End für seinen Service zuständig. Alle sind bspw. gefragt, wenn es Probleme auf der Produktionsumgebung gibt. Auch hierfür gibt es ein passendes DevOps-Prinzip: You build it, you run it.

Aktuelle Organisationsformen wie komplizierte Prozesse oder strikte Aufgabenteilung bestehen oft aus Angst vor Fehlern und mangelndem Vertrauen den eigenen Mitarbeitern gegenüber.

Doch: Nur wer keine Angst hat Fehler zu machen, hat auch den Mut neue Dinge auszuprobieren und Probleme anzusprechen. Innovation braucht den Rückhalt der Kollegen und die Courage jedes einzelnen, um etwas Neues schaffen zu wollen.

Nicht umsonst lautet ein DevOps-Prinzip auch: Fail fast, learn fast.

Deshalb plädiere ich dafür, eine offene Fehlerkultur zu etablieren: Fehler dürfen gemacht werden. Wichtig ist, dass diese kommuniziert werden, sodass alle daraus lernen können.

Zusätzlich zu den Fehlern Einzelner müssen Metriken gesammelt werden, um den Erfolg der Arbeit des Teams zu messen: Ist der neue Code besser als der alte? Machen die neuen Features unsere Kunden produktiver?

Morgens am Kaffeeautomaten eine Idee haben und am Nachmittag nutzen die ersten Kunden das Feature? Für ein Team mit Handlungsfreiheit, das auf automatisierte Prozesse zurückgreift und keine Angst vor Fehlern hat, ist das keine Utopie.

Wenn wir zusätzlich aus Verhaltensdaten des Kunden ableiten, wie wir ihm das Leben leichter machen können, entsteht ein wirklich innovatives Produkt mit kurzer Time-to-Market. An ein solches Produkt – das wirklich den Anspruch hat, dem Benutzer zu helfen – binden sich Kunden gerne.

Die drei vorgestellten Prinzipien sind ein kleiner Teil der DevOps-Kultur. Seit einigen Jahren ändern diese Prinzipien nicht nur die klassische Produktentwicklung, sondern ganze Firmenstrukturen und Kollaborationskonzepte.