DevOps (zusammengesetzt aus „Development“ Entwicklung und „Operations“ Betrieb) ist eine Software-Entwicklungsmethode , die Kommunikation, Integration, Automatisierung und die Zusammenarbeit zwischen Software-Entwicklern und anderen Fachkräften betont.

Betrachtet man die Unternehmen, die oft als Beispiel für erfolgreiches DevOps (Netflix, etsy.com, Wooga, Amazon, Google, etc.) herangezogen werden, wird deutlich, dass die Wertschöpfung dieser Firmen in der Produktherstellung liegt. Dementsprechend ist es naheliegend, dass DevOps dort funktioniert, da die Unternehmen ja daran interessiert sind ihre Wertschöpfungskette ständig zu verbessern. Der Einbezug des Betriebes (Operations) in die Entwicklung (Development) ist eine natürliche Konsequenz der kontinuierlichen Optimierung und Automatisierung der Prozesse, die sich bei einem „Produkt“ nur selten ändert.

Doch was, wenn ein Unternehmen kein Produkt anbietet? Als Dienstleister haben Agenturen zusätzliche Herausforderungen bei der Einführung von DevOps. Die Projekte haben kurze Laufzeiten, so dass sich eine Routine kaum einstellen kann. Ständig neue Kunden, die oft noch nie etwas von Continuous Delivery gehört haben und Agile nur aus der Theorie kennen. Immer wieder neue Software. Und der Betrieb – nun, der ist ausgelagert an einen externen Dienstleister des geringsten Misstrauens oder wird vom Kunden selbst übernommen. Können solche Unternehmen überhaupt DevOps einführen?

Auf der DevOpsCon 2015 fragte Jesper Richter-Reichhelm (Wooga) während seiner Session „Innovation dank DevOps“ das Publikum, wie es denn wäre, wenn sie die Möglichkeit hätten, die gleiche Software noch mal zu entwickeln. Würden sie dann nicht alles anders und vor allem besser machen? Genau diesen glücklichen Zustand haben die meisten Webagenturen: Vergleichsweise kurze Projektlaufzeiten mit einem ähnlichen Ziel. Dies sollte man nutzen und immer wiederkehrende Tätigkeiten automatisieren.

An dieser Stelle hört man oft das Gegenargument, dass sich bestimmte Aufgaben nicht automatisieren lassen, obwohl sie immer wieder anstehen. Ein Beispiel hierfür sind die Importschnittstellen in einem Shop-System wie z.B. bei der eCommerce Software Magento. Jeder Kunde hat ein eigenes PIM (Product Information Management ), welches die Daten anders bereitstellt als das PIM des Kunden aus dem letzten Projekt. Und dann hat der Kunde auch noch ganz andere Anforderungen an den Shop, so dass die Datenstruktur völlig anders ist als beim lezten Mal. Und doch: Man braucht bei jedem Projekt einen Datenimport vom PIM in den Shop.

Lässt sich etwas nicht automatisieren, dann betrachte man es nicht abstrakt genug. Der Grund, warum die meisten Systeme (vor allem im Webumfeld) keine „generischen“ Schnittstellen haben, ist gleichzeitig die Lösung des o.g. Problems: Wurde der Import einmal realisiert, dann kann dieser über Jahre hinweg genauso benutzt werden, ohne das Anpassungen nötig werden. Betrachtet man das Projekt für sich, stehen die Kosten einer generischen Schnittstelle nicht in Relation zum Nutzen. Weder dem Kunden noch den Entwicklern des Systems hat sich diese Anforderung je gestellt. Als Dienstleister hat man bereits unzählige solcher Projekte realisiert und daraus das nötige Know-how gewonnen, um eine generische Schnittstelle zu entwickeln. Damit ist man den ersten Schritt Richtung eigenes Produkt gegangen. Genau wie jede andere Software muss auch diese gewartet, versioniert, paketiert, konfiguriert und ausgeliefert werden. I.d.R. lässt sich eine solche Schnittstelle nicht direkt verkaufen, kann aber einen Vorteil gegenüber der Konkurenz verschaffen und wird vom Vertrieb gerne als „das Verkaufsargument“ ins Feld geführt.

Dem Problem mit dem „fehlenden“ Betrieb sollte man so begegnen, dass man kurzer Hand anfängt, eigene Server zu betreiben. Was spricht gegen Test- und Staging-Server, welche von den Projektteams eigenständig betrieben werden? Nur so bekommen die Entwickler ein Gefühl für ihre eigene Software und können neues Know-how im Unternehmen aufbauen. Die individuellen Anforderungen des Kunden an den Release- und Deployment-Prozess sollten klar definiert und vor allem im Projekt gelebt werden. Ähnlich wie durch Test-driven Development verändert sich die Architektur der Software, wenn man sich vor der Implementierung Gedanken über den Betrieb und das Deployment macht.

DevOps: warum es für alle Beteiligten im Dienstleistungsbereich sinnvoll ist

Die meisten Entwickler (vor allem in Agenturen) gehen davon aus, dass die Software einfach „läuft“, wenn man sie (fast) fehlerfrei ausgeliefert hat. Sie kennen den Betrieb nicht und sehen somit auch nicht die damit verbundenen Probleme. Es öffnet einem die Augen, wenn man sich das erste Mal ernsthaft mit dem Thema Deployment beschäftigt. Holt man nun den Hosting-Dienstleister sowie die IT des Kunden mit ins Boot, kann man von ihnen viel lernen und vor allem Lösungen für die nun gemeinsamen Probleme suchen. Gleichzeitig hat man sie in den eigenen agilen Prozess eingebunden und ist nicht länger davon abhängig, wann der Dienstleister das aktuelle Release ausrollt, um das Feedback vom Kunden zu bekommen.

Mit dem neuen Know-how kann die Agentur der Dienstleistungspflicht viel besser nachkommen und den Kunden über Continious Delivery, Deployment, Monitoring, Konfigurationsmanagement, Dokumentation, Testing, Sicherheitschecks, Berechtigungskonzepte oder kurz „Betrieb“ beraten. Die Dienstleistung wird zum Produkt — und DevOps ein wichtiger Bestandteil davon.

Autor: Vadim Justus