So führen Sie DevOps ein, ohne das Budget zu sprengen
Das Implementieren von DevOps ist teuer – manchmal zu teuer. Unternehmen sollten daher die Transformation besser langsam angehen und sich fragen, was sie wirklich brauchen.
Wenn es um Unternehmenskultur in IT-Betrieben geht, herrscht kein Mangel an neuen Ideen und Konzepten mit klingenden Namen. Viele erinnern sich noch daran, als ITIL der letzte Schrei waren, hinzu kamen SCRUM, Agile und natürlich auch DevOps
Die Herausforderung für die IT besteht nicht nur im Durchdringen dieser Buchstabensuppe mit endlosen Akronymen, sondern auch darin, dass diese Änderungen und Konzepte die Gruppendynamik und Arbeitsweise von IT-Teams durchdringen. Flexibilität war dabei schon immer wichtig, da nicht nur die Kultur ständig in Bewegung ist, sondern auch technische Neuerungen am laufenden Band dazu kommen. Viele dieser Begriffe stammen aber von außerhalb der IT und von Managern, die versuchen, Teams nach ihren Bedürfnissen und Ansprüchen zu formen. Die vollständige Umsetzung der Struktur vieler formaler Frameworks – zum Beispiel ITIL – ist finanziell und personell eine kaum zu bewältigende Herausforderung für die meisten Unternehmen.
Das führt dazu, dass viele Organisationen nur Teile einer neuen Struktur wählen und in ihre IT-Abläufe einpassen, je nachdem, was finanziell vertretbar und lohnend ist. Das weist bereits daraufhin, dass DevOps sich wesentlich kosteneffizienter einführen lassen, wenn dies nicht auf einen Rutsch geschehen muss – sondern in realistische Etappen eingeteilt wird.
DevOps gibt es nicht geschenkt
DevOps ist per Definition eine Sammlung von Praktiken, welche die Softwareentwicklung mit dem IT-Betrieb zusammenbringen, um Lebenszyklen zu verkürzen und eine kontinuierliche Bereitstellung (Continuous Delivery, CD) in hoher Qualität zu unterstützen.
Darüber hinaus eignen sich DevOps nur für bestimmte Projekte und für andere nur teilweise; die meisten Unternehmen – beispielsweise in der Finanz- oder Gesundheitsbranche – streben gar nicht mehrere Releases pro Tag an. Die Art und Weise, wie die Anwendungen im Unternehmen funktionieren, gibt die Richtung für die Diskussion rund um DevOps vor. Selbst, wenn IT-Teams sich am Ende gegen DevOps entscheiden, können sie aus dieser Debatte viel mitnehmen.
Die Art und Weise, wie die Anwendungen im Unternehmen funktionieren, gibt die Richtung für die Diskussion rund um DevOps vor.
IT-Organisationen können rund um DevOps einige Konzepte finden, die den Geschäftsanforderungen entsprechen, ohne den vollen DevOps-Sprung zu wagen. Im Folgenden heben wir zwei Schlüsselbereiche hervor, von denen viele Unternehmen profitieren können: Versionsverwaltung und Automatisierung.
Versionsmanagement
Versionsmanagement-Tools und -techniken haben sich im Laufe der Jahre geändert, ihre grundlegende Prämisse jedoch nicht. Wenn Sie eine Änderung an einer Anwendung vornehmen, erhöhen Sie einen Revisionsbuchstaben oder eine Build-Nummer und dokumentieren die Änderung. Diese einfache Vorgehensweise hilft Teams dabei nachzuvollziehen, welche Änderung für einen Fehler verantwortlich ist.
Versionsverwaltung ist nicht dasselbe wie Änderungsmanagement: Bei der Versionsverwaltung geht es darum, Änderungen zu dokumentieren und zu verfolgen. Beim Änderungsmanagement geht es darum, die Änderung über Genehmigungsschritte in der Dokumentation zu kontrollieren.
Bei DevOps dreht sich alles um Agilität und die Verkürzung der Entwicklungszeit. Änderungsverwaltung kann je nach Dauer des Genehmigungsprozesses die Geschwindigkeit der Entwicklung negativ beeinflussen. Das Ersetzen des Änderungsmanagements durch eine Versionsverwaltung verleiht IT-Teams mehr Agilität und Geschwindigkeit. Eine enge Dokumentation und klare Verantwortlichkeitsstrukturen bleiben erhalten, während es weniger Pausen im Prozess für das Einholen von Genehmigungen gibt.
Einige Leute argumentieren, dass diese Methode das Risiko erhöht. Aber das System, das den Fortschritt für das Überprüfen der Dokumentation unterbricht, hat auch den Nachteil, dass es nicht-IT-Experten miteinbezieht, die den vollen Umfang und die Auswirkungen der vorgeschlagenen Änderung nicht verstehen. Unternehmen sollten sicherstellen, dass der Papierkram unabhängig vom bestehenden Workflow korrekt ist, aber im Idealfall Verzögerungen durch unnötige Prüfschritte vermeiden.
Automatisierung
Fast sämtliche Aufgaben und Workflows können von Automatisierung profitieren. Qualitätskontrolle und Software-Releases sind Paradebeispiele dafür – und das nicht nur wegen der schnelleren Abläufe. Wenn es um Softwaretests und -freigaben geht, ist Konsistenz der entscheidende Vorteil; eine höhere Geschwindigkeit ist dabei nur der Bonus.
Variablen können beim Testen zu unerwarteten Ergebnissen führen, die dann die Bereitstellung verzögern. Ein solider, konsistenter Testplan ermöglicht es IT-Teams, den Aufwand zu reduzieren und Ergebnisse nach einzelnen Änderung zu filtern. Diese Testergebnisse geben direkt die Auswirkungen von neuen Versionen wieder und enthalten keine irrelevanten Zusatzdaten.
Eine bedachte, schrittweise Umsetzung von DevOps kann es Mitarbeitern ermöglichen, bei der Transformation mehrere Rollen gleichzeitig auszufüllen. Änderungen, wie zum Beispiel das Versionenmanagement, sind nicht so groß, dass sie sich auf die gesamten bestehenden Arbeitsabläufe auswirken würden.
Das Problem mit DevOps ist unter anderen, dass der Begriff eine Menge unterschiedlicher Methoden und Konzepte umfasst – manchmal ist nicht ganz klar, was dazu gehört und was nicht. Es ist daher vollkommen korrekt und richtig, wenn Unternehmen sich nur die Rosinen herauspicken, die sich in ihren konkreten Betrieb problemlos einfügen lassen.
