„Herzlichen Dank Puzzle, dass wir dieses Jahr die DevOpsDays Konferenz in Zürich besuchen durften!“ Die beiden Members Franziska Bühler und Christoph Raaflaub fassen in folgenden Blogpost ihre Highlights zusammen.
Bereits während des Openings am ersten Tag wurde deutlich, dass sowohl bei der Organisation und Durchführung als auch bei der Speakerauswahl Profis am Werk waren. Professionell und äusserst sympathisch führten uns Martin Thalmann und Matías E. Fernández während zwei Tage durch das Programm. Sogar Besucherfeedbacks wurden mittels Feedbackloops sofort umgesetzt, um dem Publikum ein noch besseres Erlebnis zu gewährleisten. Besonders die gute Durchmischung von technischen und kulturellen Talks hat uns angesprochen.
Unsere Highlights
Reliability Engineering
Mary Poppendieck mit ihrem Talk “Mary Poppendieck – Reliability Engineering – The Essential Discipline for Complex Systems” zeigte uns auf, dass nicht nur Redundanz, sondern auch Isolation für die Site Reliability sehr wichtig ist. Und sie machte klar: “Things will crash. Deal with it!”
Mary thematisierte auch die Herausforderungen und Challenges an einen SRE in der sich verändernden Umgebung von Enterprise Size Installations zu Internet Scale Installations und dass ein “Error Budget” genügt und “Reliable Enough” ist. Sie arbeitet schon seit 1972 als Reliability Engineer, was ihrem Vortrag noch mehr Relevanz und Glaubwürdigkeit verlieh. Wir waren begeistert!
Remote Work Prinzipien
Im Vortrag „What Colocated Teams Can Learn From Remote Teams” teilte Noelle Daley ihre Erfahrungen bezüglich Herausforderungen von Remote Work. Sie thematisierte unter anderem «Information Siloing», «Empathy» und «Work-life Separation» und zeigte, dass diese mit einer Transformation von impliziter zu expliziter Kultur gelöst werden können. Zu einer expliziten Kultur gehört unter anderem die Dokumentation von Entscheidungsprozessen, die angemessene Nutzung von Telefonanrufen und Chatnachrichten (nur bei benötigter schneller Rückmeldung) und der persönliche eigene Entscheid jedes Mitarbeiter, wo und wann er am besten arbeiten kann.
Jenkinsfile Runner
Oleg Nenashev verlieh uns mit dem Vortrag „Under the hood of serverless Jenkins. Jenkinsfile Runner“ Einblick in Jenkins.
Bei Puzzle ITC wurde Jenkins bereits als Buildserver eingesetzt, als er noch unter dem Namen Hudson stand. Aktuell wird die Mehrheit unserer Projekte Builds mit Jenkins automatisiert. Ich (Christoph) benutze in meinen Projekten oft den Ansatz der Pipelines as Code mit den Jenkins Pipeline Files. Puzzle hat dazu auch ein frei verfügbares Techlab erstellt: Jenkins Pipeline Techlab
Wie wird so eine Pipeline entwickelt und getestet?
Oleg hat in seiner Präsentation den Jenkinsfile Runner vorgestellt. Dies ist eine CLI, mit welcher die Pipeline lokal auf dem Rechner ausgeführt werden kann. Aber nicht nur dort, denn mit dem Jenkinsfile Runner ist es möglich, den Build auf allen Umgebungen gleich auszuführen (Docker Ansatz).
Retros
Durch die Präsentation «Retros are the New Black: How to Cultivate Continuous Improvement Across Teams» von Jacqueline Sloves wurde uns in Erinnerung gerufen, dass es nicht reicht, in einem Retro alle positiven und negativen Punkte zu sammeln. Sie sollten unbedingt priorisiert, in einem Follow Up Meeting weiterverfolgt und entsprechende Massnahmen getroffen werden.
Deployment Pipeline Qualität
Mit dem Talk „Turning the Quality of Your Deployment Pipeline into a Team Task“ hat uns Areti Panou das Problem des Zuschauereffekts aufgezeigt und wie es gelöst werden kann. Jeder Pipeline Step hat seinen Zweck und sollte gut dokumentiert werden. Areti hat sogar vorgeschlagen, für jeden Step einen Elavator Pitch zu erstellen. Jeder Step sollte auch in seiner Wichtigkeit definiert werden und in welchem Zeitraum er repariert werden muss. Wenn die Deadline überschritten wird, muss die Änderung rückgängig gemacht werden.
Um den Zuschauereffekt zu umgehen, sollte jedem Problem in der Pipeline automatisch eine Person (Owner) zugewiesen werden. Sie ist verantwortlich, dass das Problem behoben wird. Die Person muss den Fix nicht selbst programmieren, muss ihn aber koordinieren.
Sichere Delivery Pipelines
Nicolas Byl hat uns aufgezeigt, wie Delivery Pipelines abgesichert werden können: Securing the “other” supply chain.
Sobald die Delivery Pipeline Hybrid wird und nicht mehr vollständig im internen Netzwerk der Firma läuft, braucht es Mechanismen zur Sicherheit und Nachvollziehbarkeit. Zum Beispiel wurde in der Autoindustrie Checklisten verwendet, welche ausgefüllt und unterschrieben wurden. So konnte bei der Herstellung eines Autos in jedem Schritt nachgeschaut werden, wer wann was gemacht hat. Dies kann auch bei der Software Entwicklung eingesetzt werden. Dabei werden wichtige Zwischenschritte digital signiert. Beispielsweise kann ein Git Commit einfach vom Entwickler signiert werden. Diese Signatur wird vom Buildserver überprüft und die Pipeline geht nur dann weiter, wenn es eine valide Signatur ist. Dies kann auch auf weitere Artefakte angewandt und somit eine konforme Delivery Pipeline aufgebaut werden.
Open Spaces
Die Nachmittage waren den Open Spaces gewidmet. Jeder Teilnehmer konnte sein Thema eingeben, welches danach mit interessierten Personen diskutiert wurde.
In einem Open Space zum Thema „Monitoring in DevOps“ haben wir uns über Prometheus ausgetauscht. Es wurden Installation verglichen, Alerting Lösungen angeschaut, Whitebox Monitoring dem Blackbox Monitoring gegenübergestellt, Gruppierung/Abhängigkeiten der Komponenten bei Alerts und noch vieles mehr.
APPUiO-Stand
Auch APPUiO war mit ihrer Containerplattform als Sponsor vor Ort. Leider hat niemand von uns beiden den Highscore im Arcade Pac-Man erreicht, so dass wir nicht Gewinner der Lego Saturn V Rakete wurden. Lies mehr über APPUiO und ihrem Stand in ihrem aktuellen Blogpost.
Trotzdem gehen wir beide mit einem vollen Rucksack nach Hause… einem Rucksack voller Ideen und Eindrücken. Herzlichen Dank!