Agile, DevOps und Continuous Delivery – eine Bestandsaufnahme

Meyen: All diese Faktoren zusammengenommen werfen doch die Frage auf: Warum jetzt? Diese Idee hätte doch vor zehn Jahren schon entstehen können.

Fowler: Ist sie ja.

Meyen: Tatsächlich?

Fowler: Ich erinnere mich noch, als ich Kent Beck 1997 in der Schweiz besuchte, während er gerade an einem Projekt arbeitete. Er baute ein System für Lebensversicherungen. Das System wurde in Smalltalk entwickelt und Kent hat jeden Abend eine neue Version in den Produktionsbetrieb gebracht. Das ist genau das, was Continuous Delivery ausmacht: das regelmäßige Vorantreiben des Produktionsablaufs. Die Sache war nun die, dass er sich in einer Smalltalk-Umgebung bewegte, in der Vieles möglich war. In den letzten zehn Jahren hingegen haben wir in viel komplexeren Umgebungen mit viel mehr beweglichen Teilen gearbeitet. Es ist die weitaus größere Herausforderung, diese Abläufe in einem solchen Umfeld umzusetzen. Darin besteht ein wesentlicher Teil unserer beratenden Tätigkeit der letzten zehn Jahre: immer wieder darüber zu sprechen, dem Kunden Vorschläge zu unterbreiten und ihn in die richtige Richtung zu bewegen. Wir haben in dieser Zeit eine Menge gelernt, und wir haben einige der Leute, die sich schwerpunktmäßig damit befasst haben, überzeugt, ein Buch darüber zu schreiben.

Dörnenburg: Wir sollten nicht vergessen, dass das Buch eine Sammlung von in der Praxis erprobten Praktiken ist. Es ist also klar, dass diese Praktiken nicht erst jetzt neu erfunden wurden.

Schlegel: In der Frage „Warum jetzt?“ spiegelt sich doch die Tatsache wider, dass man sich auf dem Markt des Prinzips der Continuous Delivery nicht bewusst war und dachte, es sei etwas neues und aufregendes. Wenn man sich die Geschichte der Softwareentwicklung und -methoden anschaut, stellt man fest, dass sich einige nur auf Analyse – Coden – Testen konzentrierten. Alles, was die Produktionsumgebung betrifft, findet erst am Ende vieler vorangehender Iterationen statt. Und wenn man sein Augenmerk nur auf den ersten Teil legt, spart man die letzte Meile aus. Hier setzt Continuous Delivery an: Diese letzte Meile wird in den Entwicklungsprozess hineinverlegt und somit wird auch die Zeit zur Markteinführung verkürzt. Die letzte Meile ist schmerzhaft, wenn man sie nur viermal pro Jahr auf sich nimmt.

Meyen: Welche Konsequenz müssen Entwickler daraus ziehen? Müssen auch sie umdenken?

Dörnenburg: Entwickler müssen Operations lieben lernen, was sie derzeit nicht tun. Die Teams haben oft gegenläufige Ziele und streiten sich. Das zu überwinden ist der größte Schritt. Es gibt eine Unterbewegung, die sich DevOps nennt, meiner Ansicht nach der Schlüssel in dieser Entwicklung. Die Zusammenarbeit ist wichtig, was auch bedeutet, dass Werkzeuge in beide Richtungen funktionieren müssen. Entwickler müssen also ein bisschen mehr über die traditionellen Infrastrukturtools wissen, und die Zuständigen für Infrastruktur oder Betrieb müssen mehr über die Entwicklerwerkzeuge, -praktiken usw. lernen. Das bedeutet keineswegs, dass Spezialisierungen unmöglich sind. Es wird Leute geben, die sich selbst eher als Ops oder eher als Devs verstehen. Aber sie müssen viel enger zusammenarbeiten und die Werkzeuge des anderen kennen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.