DevOps: Die fünf grössten Denkfehler

Alle reden von DevOps. Wer hätte nicht gern schnelle, einfache, fehlerfreie Releases seiner Software ohne Reibungsverluste zwischen Auftragnehmer, Entwicklung und Betrieb? Urs Breu arbeitet seit drei Jahren mit dem Ansatz und kennt die klassischen Denkfehler.

1. Einer soll’s richten!

Du wurdest in deinem Team als DevOps-Verantwortlicher bestimmt und darfst nun dafür sorgen, dass diese Methodik bei der Softwareauslieferung umgesetzt wird? Freu dich nicht zu früh! Du bist nun nämlich nicht nur der letzte, der abends aus der Tür geht, sondern auch der Flaschenhals im Projekt. DevOps müsste stattdessen bedeuten, dass der Prozess so weit wie möglich automatisiert und von einer einzelnen Person unabhängig gemacht wird. Am Anfang macht man zwar meist mehr «Handarbeit», aber im Projektverlauf können und müssen die Abläufe immer mehr automatisiert werden. Jeder Engineer soll genug vom Prozess verstehen, dass er eine Lieferung machen kann. Im Idealfall kann sogar der Kunde selber Software deployen, ohne nochmal mit den Engineers Rücksprache nehmen zu müssen.

2. Testen dauert zu lang!

Auch bei Projekten mit DevOps-Ansatz stehen meiner Erfahrung nach am Anfang oft manuelle Tests. Die sind schon ok, dauern aber für die kurzen und häufigen Releasezyklen viel zu lang. Wir haben in unseren Projekten die meisten Tests automatisiert. Mit der Zeit vertrauen uns die Kunden auch wirklich, dass diese Tests gut und ausreichend sind und sie darum viele Testdrehbücher schreddern können. Und übrigens: Ein automatisierter Test, der 8 Stunden dauert, ist ein schlecht konzipierter Test.

3. Aus den Augen, aus dem Sinn

Wie gut, die Software ist beim Kunden, ich muss mir keine Gedanken mehr machen. Eigentlich die Idealvorstellung jedes Entwicklers. In Realität kommt Tage später der Telefonanruf, dass etwas nicht funktioniert. Überwachen wäre gut gewesen. Das gilt schon für klassische Projekte, umso mehr für DevOps mit Auslieferungen im Stundentakt. Für einen sorglosen Schlaf sorgen hier Tools, die das System rund um die Uhr automatisch überwachen und jeden Schluckauf umgehend zurückmelden. So hatten wir dank Monitoring zum Beispiel mal komfortable drei Tage Zeit, um ein Filesystem vor dem endgültigen Überlaufen zu flicken.

4. Bananen-Software

DevOps ist das perfekte Bananen-Software-Lieferungstool. Man kann dem Kunden nach seinen Wünschen unreife Software liefern und ihn damit sich selbst überlassen. Aber nur weil man etwas sehr schnell und «transparent» ausliefern kann, muss man das nicht tun. Als Engineer habe ich die Verantwortung für das konsistente Produkt, die geeignete Architektur und Technologiewahl und will den Kunden in der Hinsicht immer gut beraten. Der DevOps-Prozess fängt für mich beim Requirements Engineering an und endet bei der Qualitätssicherung.

5. DevOps rettet die Welt

Meinst du wirklich, DevOps ist die Lösung aller Probleme? Spätestens nach der siebten bahnbrechenden Methodik habe ich aufgehört zu zählen. Aber tröstlich ist es trotzdem, dass praktisch alle Aspekte von DevOps auch in allen anderen IT-Projekten angewandt werden können und dort wirklich gute Dienste leisten.