Interview mit DevOps Evangelist Anton Weiss

„Dein Code ist ein Minenfeld – es wird Verluste geben!“

Gabriela Motroc

Anton Weiss

Continuous Delivery ist das Gegengift für stressige Releases. Wir haben Anton Weiss, DevOps-Evangelist und CEO von Otomato, eingeladen, mit uns über Best Practices für das Aufsetzen einer effektiven CD-Pipeline zu sprechen. Wie schafft man es, damit der eigene Code nicht zu einem Minenfeld für kontinuierliche Releases wird?

Continuous Delivery ist kein rein theoretisches Konzept mehr, aber das bedeutet nicht, dass es bereits von allen Unternehmen in der Praxis umgesetzt wird. Wir sprachen mit Anton Weiss, Principal Consultant / CEO von Otomato und DevOps-Evangelist, über die Vorteile von Continuous Delivery und die Gefahren, sie zu ignorieren.

JAXenter: Hallo Anton! Continuous Delivery revolutioniert gerade die IT. Haben wir damit den besten Weg gefunden, um Software auszuliefern?

Continous Delivery ist zurzeit der beste Weg, um Software auszuliefern.

Anton Weiss: Nun, wir wissen noch nicht, ob es der beste Weg ist. Die IT-Branche verändert sich schnell und neue, verbesserte Techniken und Methoden werden womöglich in diesem Augenblick erfunden und angewendet. Dennoch ist Continuous Delivery zurzeit der beste Weg, den wir kennen, da es:

  • Flexibilität erhöht,
  • Transparenz ermöglicht,
  • Qualität verbessert,
  • Unsicherheit, Nacharbeit und – effektiv – menschlichen Burnout reduziert.

Ich denke, das Wichtigste ist dabei, die Definition für Continous Delivery einfach zu halten. Interessanterweise hatten einige Organisationen, mit denen ich in der Vergangenheit zusammen arbeiten durfte – besonders Firmen, die nicht-SaaS Lösungen entwickeln – einige Schwierigkeiten mit der konkreten Beschreibung, was CD eigentlich ist. Obwohl es im Grunde ziemlich einfach ist: Continous Delivery bedeutet, kontinuierlich dazu im Stande zu sein, Software auszuliefern, ohne die Qualität zu beeinträchtigen.

Mir ist klar, dass das schnell zu definieren aber nicht so leicht zu implementieren ist, da wir dafür Werkzeuge und Prozesse benötigen, die Fragen beantworten können wie:

  1. Wer ist unser Kunde?
  2. Wie nutzt unser Kunde unsere Software?
  3. Was ist der letzte gute Build unserer Software?
  4. Welchen Inhalt hat der letzte Build? (Features, Bugfixes, Drittanbieter-Integrationen, Änderungen in der Konfiguration)
  5. Durch welche Tests ist der Build gelaufen? Wie war die Coverage-Rate?
  6. Können wir ein One-Click-Deployment des Builds durchführen?
  7. Wie messen wir Qualität und Performance?
  8. Wie führen wir im Falle eines Fehlers einen sicheren Roll-back durch? Das kann auch ein Roll-forward oder ein Feature-Toggling bedeuten. Ziel ist es, die MTTR – Mean Time To Restore – gering zu halten.

Sollten wir eine dieser Fragen nicht beantworten können, sind wir zum Scheitern verurteilt. Wenn wir den Kunden nicht verstehen, werden wir die falschen Abläufe testen und womöglich gar nicht bemerken, dass unsere Software nicht richtig funktioniert. Wenn wir keine definierten Quality Gates haben, können wir die Software womöglich übergeben, aber nicht mit gutem Gewissen releasen. Wenn wir die Test-Coverage nicht messen, werden unsere kontinuierlich ausgelieferten Änderungen nicht vernünftig getestet. Wenn wir den Content nicht managen, können wir vermutlich releasen, werden es aber schwer haben, etwaige Schäden rückgängig zu machen – und Schaden wird es geben!

Hierzu vielleicht eine Anekdote eines unserer Kunden: ein kleines Web-Startup im Bereich Sharing Economy. Das Unternehmen arbeitete nach dem Lean-Prinzip und hatte seine Struktur  größtenteils gut aufgestellt – ein CI-Server, Staging-Environment, einige Testroutinen, ein Promotion Process. Allerdings hatten sie kein Delivery Content Management und keine Test-Coverage-Metriken. Sie wollten kontinuierlich ausrollen, sobald sie das Gefühl hatten, bereit dafür zu sein  – gemessen an Testergebnissen oder Intuition – oder wenn ein wichtiger Bugfix nötig wurde.

Aber dann kam es zu Fehlern, und sie konnten nicht mit Sicherheit sagen:

  • welche Änderung den Bug zur Folge hatte.
  • zu welcher Version sie zurückgehen sollten.
  • ob es Schema-Änderungen zwischen der guten und der schlechten Version gab.

Nach einigen Monaten endloser Brandbekämpfung, anstrengenden Nachtschichten mit dem Versuch, den Service wiederherzustellen, und der Kündigung einiger zentraler Entwickler begann das Unternehmen, nach einer neuen Lösung zu suchen. An dieser Stelle kamen wir ins Spiel und halfen, ihre CD-Pipeline zu überarbeiten und ihnen am Ende tatsächlich den Nutzen zu bringen, den sie erhofft hatten.

Das Gegengift für stressige Releases

JAXenter: Welche möglichen Probleme vermeiden wir, wenn wir CD die gebührende Aufmerksamkeit widmen?
Anton Weiss: Das größte Problem, das Continuous Delivery zu verhindern hilft, sind stressige, anfällige Releases, vor denen jedesmal alles erzittert aus Angst, ob dabei auch alles gut gehen wird. In den meisten Organisationen, die CD nicht praktizieren, erfordert ein Release das Einfrieren der Codebasis. Von den Mitarbeitern wird erwartet, Überstunden zu leisten. Alles nur, weil jeder weiß, dass die eigene Codebasis ein Minenfeld ist und es jetzt alle Minen zu entschärfen gilt – und dennoch wird es Verluste geben.

Von den Mitarbeitern wird erwartet, Überstunden zu leisten, weil jeder weiß, dass die eigene Codebasis ein Minenfeld ist.

Auf der anderen Seite gibt uns eine anständige CD-Pipeline die Gewissheit, dass die meisten Minen schon vor dem Release-Tag entdeckt und entschärft wurden, und dass selbst, wenn etwas übersehen wurde, wir einen schnellen Weg haben, den Schaden rückgängig zu machen. Und das alles, weil wir in kleinen Einheiten ausrollen und jede Änderung überprüfen. Continuous Delivery macht Releases trivial.

Das andere große Businessproblem, das ursprünglich von der Agile-Bewegung gelöst werden sollte, ist, dass wir nicht etwas liefern wollen, das der Kunde gar nicht braucht. CD hilft uns dabei, unsere Hypothese sofort zu überprüfen, anstatt Wochen oder Monate bis zum Release zu warten. Praktiken wie A/B Testing, Blue/Green Deployment, Canary Releases und Feature-Toggling sind allesamt Continuous-Delivery-fähig und ermöglichen uns eine ideale Orientierung an sowohl dem Bedarf unseres Kunden, als auch dem Bedarf des Marktes.

Automatisierung und Messung – ein Must-have

JAXenter: Wie reagieren Menschen deiner Erfahrung nach auf die Idee der Automatisierung?

Anton Weiss: Gute Ingenieure lieben Automatisierung, weil sie es ihnen erlaubt, sich mit den wirklich interessanten Dingen auseinander zu setzen. Manager lieben Automatisierung, weil sie es ihnen erlaubt, effizienter zu sein. Wir alle lieben Automatisierung, weil sie die Maschinen zähmt und sie tanzen lässt. Jeder, der lange genug mit Computern gearbeitet hat, weiß, dass sie geschaffen wurden, um Menschen leiden zu lassen. Automatisierung ist unser Weg, zurückzuschlagen 😉

Wenn es also jedermann liebt, warum nutzt es dann nicht jeder? Weil Automatisierung Investitionen erfordert. Automatisierung lohnt sich auf lange Sicht immer, kann aber kurzfristig erhebliche Ressourcen verbrauchen. Und als Menschen sind wir weit mehr von Verlustängsten getrieben als von Gewinnwünschen. Wir haben Angst, Zeit zu verlieren, Leistung zu verschwenden, Fristen zu überschreiten und am Ende gar gefeuert zu werden. Viel zu oft bevorzugen wir es, unseren alten und ineffizienten Routinen zu folgen, statt in Automatisierung zu investieren. Selbstverständlich erweitert dies nur die technischen Probleme und macht alles immer fehleranfälliger.

JAXenter: Wie wichtig sind Messungen in der Praxis von CD?

Durch Messungen erkennen wir Engpässe, bevor sie uns zurück in angstgetriebene Software-Delivery-Praktiken werfen.

Anton Weiss: Die Messungen sind von entscheidender Bedeutung. Wenn man nicht testet, weiß man nicht, ob man sich verbessert oder verschlechtert, oder was und wieviel man testet. Continuous Delivery kann leicht durch unzählige Probleme behindert werden, wie z.B. Infrastruktur-Probleme, Kommunikationsmängel und unkontrollierte oder fehlende Ressourcen. Gute Messungen ermöglichen es uns, diese Engpässe frühzeitig zu erkennen und ihnen gerecht zu werden, bevor sie unseren CD-Zyklus brechen und uns zurück in manuelle, angstgetriebene Software-Delivery-Praktiken werfen.

Es gibt drei Kategorien von Messungen, die kontinuierlich in eine Pipeline einbaut werden müssen, und zwar alle im Zusammenhang mit Geschwindigkeit, Qualität und Leistung. Wir arbeiten zurzeit an einer Publikation zu den wichtigsten Metriken der einzelnen Kategorien.

JAXenter: Ist CD noch ein theoretisches Konzept oder beginnen wir bereits, den Nutzen zu erkennen?

Anton Weiss: Lange vorbei sind die Zeiten, als CD ein theoretisches Konzept war. Heutzutage ist es der Standard. Auf diese Weise veröffentlichen die sogenannten Uniorns ihre Software, und viele IT-Unternehmen (z.B. AT&T, HPE) zogen bereits nach. CD zu konstruieren erfordert Zeit, Wissen und Einsatz. Es ist nichts, das man von der Stange kaufen kann. Vor einigen Jahren habe ich sogar einen Vortrag namens „Continuous Delivery is Not a Commodity“ gehalten. Genau aus diesem Grund kommen Unternehmen erst nachträglich auf die Idee. Aber selbst diejenigen, die CD noch nicht praktizieren, bemerken, dass sie es praktizieren sollten.

Vielen Dank für dieses Gespräch!

 

anton weissAnton Weiss ist Consultant und CEO bei Otomato, einem Unternehmen, das sich auf effektive Software-Auslieferungen spezialisiert hat. Auf Twitter ist er unter @antweiss zu finden.

 
 

 

Geschrieben von
Gabriela Motroc
Gabriela Motroc
Gabriela Motroc ist Online-Redakteurin für JAXenter.com. Vor S&S Media studierte Sie International Communication Management an der The Hague University of Applied Sciences.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: