Luca und Falko besprechen Behaviour Driven Development (BDD), eine Technik zum Erstellen automatisiert testbarer Spezifikationen — testgetriebene Entwicklung auf Feature-Ebene.
https://en.wikipedia.org/wiki/Behavior-driven_development
Gojko Adzic, „Specification by Example“, ISBN 978-1617290084
Observability (kurz: O11y) ist eine wichtige Komponente von DevOps. Darüber sprechen wir mit dem QA-Experten und Observability-Fanatiker Alden Peterson von Netflix.
Dies ist der zweite Teil der Unterhaltung, die wir in der vergangenen Folge begonnen haben.
Observability (kurz: O11y) ist eine wichtige Komponente von DevOps. Darüber sprechen wir mit dem QA-Experten und Observability-Fanatiker Alden Peterson von Netflix.
Diese Unterhaltung war so fruchtbar und interessant, daß wir uns ein weiteres Mal dazu entschlossen haben, sie in zwei Teile aufzuspalten.
Dierk und Luca waren beim APMG LevelUp Event als Diskussionsteilnehmer eingeladen. Das Thema war: „After Service Management, should I learn DevOps and SRE?“
Die Unterhaltung streifte verschiedene Sichtweisen auf SRE, DevOps und ITIL, und wie man die drei Ansätze am besten in Einklang bringen könnte.
Dierk und mir hat es gut gefallen: die Diskussionen waren fachlich spannend und menschlich sehr angenehm.
Wer sich die Aufzeichnung ansehen möchte, findet sie unter diesem Link: https://www.youtube.com/watch?v=0BLYZJgM-3w
Hier folgt die zweite Folge zu DevOps bei T-Systems MMS. Unsere Gäste sind weiterhin Michael Glathe und Holger Helas.
Die beiden berichten von ihrer täglichen Arbeit und helfen uns, DevOps Theorie und gelebte Praxis zu verbinden.
In Dieser Folge geht’s um’s Eingemachte: um die Menschen, mit denen man zusammenarbeitet.
Insbesondere um beliebte heiße Eisen wie die Rufbereitschaft und wie sie bei T-Systems MMS umgesetzt ist.
Außerdem sprechen wir viel über das Menschenbild und das Thema Vertrauen, die natürlich zentrale Punkte bei der Gestaltung der Zusammenarbeit sind.
Heute haben wir Michael Glathe und Holger Helas von T-Systems MMS zu Gast.
Die beiden berichten von ihrer täglichen Arbeit und helfen uns, DevOps Theorie und gelebte Praxis zu verbinden.
In der Tat war dieses Gespräch so angenehm und spannend, daß es uns nicht gelang uns kurz zu fassen, so daß wir es in zwei Folgen aufgespalten haben.
Heute hört Ihr einen etwas allgemeineren Teil, die kommende Folge wird demgegenüber etwas praxisorientierter sein.
Neues Jahr, selber Podcast: Falko, Dierk und Luca schauen auf 2021 zurück und denken darüber nach, was DevOps im Jahre 2022 wohl bedeuten mag.
Ist DevOps noch aktuell? Hat es sich in den vergangenen Jahren gewandelt (und wenn ja, wie)? Was erwartet Organisationen im Jahr 2022 im Bezug auf DevOps?
Zu Gast haben wir heute George Romanenko, einen Experten für SAFe. Mit ihm überlegen wir, inwieweit DevOps und SAFe das selbe sind oder nicht, ob das Eine das Andere benötigt, und ähnliche Fragen um die Beziehung zwischen den beiden.
George’s LinkedIn: https://www.linkedin.com/in/george-romanenko-mba-1799402b/
In dieser Folge unterhalten wir uns mit dem Automatisierungsexperten Helge Zimpel über Terraform.
Was ist es, wofür wird es verwendet, und wie fügt es sich in den weiteren Zoo von DevOps Werkzeugen ein?
Das Thema der Folge: Terraform
Die angesprochene Testframework für Terraform: Terratest
Helges Webseite: kontainer.sh
Heute hörte ich von einem Team das jeden Tag eine .csv Datei mittels FTP herunterlädt, drei Zeilen löscht, und sie dann manuell woanders hin hochlädt.
Wieso? Weil eines Tages diese drei Zeilen nicht richtig in eine Datenbank geladen werden konnten, und ihr Workaround war, diese drei Zeilen eben zu löschen.
Und das machen sie nun Tag für Tag… seit 2009.
Teils natürlich auch einfach deshalb, weil sie in einer regulierten Industrie arbeiten, und dieser Prozeß wurde irgendwann mal dokumentiert und somit verpflichtend.
(Er ist dokumentiert als „workaround für Joe’s Problem“. Keiner kann sich erinnern, wer dieser Joe eigentlich war.)
Diese Geschichte ist einerseits amüsant, andererseits aber auch lehrreich.
Ähnliche Vorgänge finden sich in praktisch jeder Organisation. Seltsame Prozesse, die irgendwann von irgendwem eingeführt wurden, und mittlerweile selbst ein Eigenleben entwickelt haben.
Und unser aller Reflex ist vermutlich, kurzerhand den beschriebenen Prozess zu automatisieren. Das ist sicherlich eine gute Idee: die Qualität wird steigen (weil keiner mal versehentlich was verkehrt macht), die Mitarbeiter Zeit und mentale Kapazität zurückgewinnen für wichtigere, wertschöpfendere Dinge.
Andererseits ist das aber vielleicht gar nicht so eine tolle Lösung: einen etwas merkwürdigen Prozeß haben wir jetzt auch noch verewigt!
In der Tat frage ich mich, ob das dem Workaround zugrundeliegende Problem nicht in den letzten 12 Jahren irgendwann den Weg des Dodo ging. Und falls es noch existiert: ob es nicht eine gelungenere Möglichkeit gibt, diesem Problem zu begegnen, z.B. durch geeignete Validierung in der Datenbank, oder was einem auch sonst so einfällt.
Diese Geschichte weist neben der unmittelbaren Moral (automatisiere es!) aber noch eine zweite, etwas indirektere auf: auch eigenwillige Lösungen sind stets Reaktionen auf reale (oder als real empfundene) Probleme, entwickeln dann aber ein Eigenleben abseits dieser Probleme. Und können somit lange weiterexistieren, nachdem das Problem aufhörte, eines zu sein.
Insofern ist der erste Schritt einer Verbesserung durch Automatisierung ein ganz anderer: sich zu überlegen, ob das Problem weiterhin besteht und ob es weiterhin so gelöst werden muß.
Automation kann eben nicht nur segensreich zur Verringerung der Arbeitslast beitragen, sondern manchmal auch Ungünstiges erst recht zementieren.