So gelingen DevOps

DevOps-Ansätze reichen bis in die späten 1990er-Jahre zurück, sie sind also prinzipiell nichts Neues. Dennoch führen viele Projekte nach wie vor nicht zum gewünschten Ergebnis. Consol zeigt auf der Basis eigener Erfahrungen aus zahlreichen DevOps-Kundenprojekten, welche fünf Punkte auf jeden Fall zu beachten sind.

1. Kulturwandel aktiv angehen

Klar ist, dass zwischen Entwicklung und Betrieb zunächst einmal ein Interessenkonflikt besteht. Sind für den Entwickler Kreativität und Flexibilität wichtig, so kommt es im IT-Betrieb vor allem auf die Kriterien Stabilität und Verfügbarkeit an.

Arbeiten im Rahmen einer DevOps-Strategie nun Entwickler und Verantwortliche für den IT-Betrieb gemeinsam in Teams an Konzeption, Entwicklung, Test und Betrieb von Applikationen, erfordert dies neben organisatorischen Veränderungen auch einen Kulturwandel.

Das bedeutet zum Beispiel auch, dass sich die Teammitglieder mit den jeweiligen Anforderungen und Prozessen sowohl von Entwicklung als auch Betrieb auseinandersetzen müssen.

Das Thema Wandel in der Unternehmenskultur muss unter Einbindung des Managements bei DevOps-Projektstart aktiv angegangen werden, um künftige Reibungsverluste in den interdisziplinären Teams zuverlässig auszuschließen.

2. Investitionsvolumen berücksichtigen

Klar ist, dass erfolgreich durchgeführte DevOps-Projekte mittel- und langfristig zahlreiche Vorteile mit sich bringen: von einer höheren Qualität und Flexibilität über schnellere Software-Releasezyklen bis hin zu Kosteneinsparungen.

Zu erreichen ist dies aber nur, wenn die erforderlichen Anfangsinvestitionen getätigt werden. Dies ist oft nicht der Fall. Jedem Unternehmen muss bewusst sein, dass die DevOps-Einführung zunächst immer mit einer Kostensteigerung im IT-Bereich verbunden ist.

Die Leitungs­ebene des Unternehmens muss deshalb von Anfang an in DevOps-Projekte eingebunden werden und alle erforderlichen Investitionsentscheidungen nachhaltig unterstützen.

3. Simulationsumgebung nutzen

Die Prozesse in der Entwicklung und Produktion unterscheiden sich erheblich. So sind zum Beispiel Applikationen in der Produktion immer in eine größere System­umgebung eingebunden.

Der Entwickler arbeitet hingegen oft völlig autark an einer Software auf seinem Desktop-PC oder Notebook, ohne dass diese beispielsweise die erforderliche Verbindung zu einem SAP-System hat.

Dem Entwickler in einem solchen Fall eine SAP-Einzelplatzlizenz bereitzustellen ist allein schon aus Kostengründen meistens kein gangbarer Weg, also wird es in der Regel unterlassen und Fehler in der Software sind damit quasi programmiert.

Die Alternative lautet: die Nutzung einer Simulationsumgebung. Dies wird von vielen Unternehmen aber nach wie vor unterlassen, obwohl es nicht zwangsläufig mit hohen Kosten verbunden ist.

Es gibt hier durchaus auch kostengünstige Open-Source-Produkte wie Citrus von Consol (www.citrusframework.org), ein plattformunabhängiges Framework, das flexibel für die unterschiedlichsten Technologien und Protokolle verwendet werden kann.

4. Manuelle Prozessschritte eliminieren

Um die vollen DevOps-Vorteile nutzen zu können, müssen natürlich möglichst auch alle Prozesse automatisiert ablaufen. Manuelle Tätigkeiten sind aber vor allem im Bereich Testing noch häufig an der Tagesordnung.

So ist es kein Einzelfall, dass Fachabteilungen die funktionale Integrität einer Applikation händisch und damit arbeitsintensiv überprüfen. Dem DevOps-Ansatz, der zu einer schnelleren Bereitstellung von Software beitragen soll, widerspricht dies aber.

Manche Unternehmen bleiben der manuellen Vorgehensweise auch deshalb treu, da etliche Testing-Tools durchaus auch mit nicht unerheblichen Kosten verbunden sind. Doch dies greift eindeutig zu kurz, da es auch in diesem Bereich Open-Source-Lösungen gibt, die eine umfassende Testing-Funktionalität bieten: von Funktions- über Last- und Performancetests bis zu End-to-End-Tests.

5. Systembrüche reduzieren

Auch in DevOps-Strukturen werden Entwicklungs-, Integrations- und Produktionsumgebung oft isoliert betrachtet. In jedem Bereich werden eigene Tools eingesetzt, die aber als Insellösungen nicht miteinander verknüpft werden.

Dies entspricht ebenfalls nicht dem eigentlich integrativen DevOps-Konzept. Ziel muss es sein, eine zentrale Vernetzung sicherzustellen. Auch hier sehen etliche Unternehmen – oft aus Unkenntnis – keine Möglichkeiten.

Es handelt sich aber ebenso um einen Trugschluss, man muss nur an Tools im Umfeld von OpenShift oder Ansible denken.