Ich wurde eingeladen, die Keynote am Baloise OpenX Day zu halten, einer internen Konferenz, an der die Baloise ihre Technologie-Community zusammenbringt. Die Session kombinierte Impulsvorträge mit interaktiven Diskussionen und gab mir die Gelegenheit, DevOps-Grundlagen zu teilen und dann direkt von den Teams über ihre echten Herausforderungen zu hören. Die Gespräche mit den Baloise-Ingenieuren waren unglaublich wertvoll, besonders zu Themen wie Continuous Deployment in regulierten Branchen und die Rolle von Platform Engineering.
DevOps ist weit mehr als Automatisierung oder Tooling: Es ist ein Zusammenspiel von Menschen, Prozessen und Technologie, um Produkte schneller, zuverlässiger und kundenorientierter zu entwickeln.
Worum es geht # Der Vortrag zeigt, warum Unternehmen vom projektorientierten Denken zum produktzentrierten Arbeiten wechseln müssen, wie eine Continuous Delivery Pipeline als Rückgrat moderner Produktentwicklung funktioniert und weshalb Qualität, Testing und Operability von Anfang an mitgedacht werden müssen.
In diesem Konferenzvortrag bespreche ich eines der grundlegendsten Themen in DevOps: das Denken in Systemen und Wertströmen. Wenn ich mit Unternehmen an ihren DevOps-Transformationen arbeite, sehe ich immer wieder dieselben Muster. Das Business hat tolle Ideen. Diese werden in Word-Dokumente und Jira-Tickets geschrieben. Dann werden sie über die Mauer der Verwirrung zum Entwicklungsteam geworfen. Das Entwicklungsteam baut etwas und wirft es zum Testing. Das Testing vergleicht die Spezifikation mit dem Gebauten (was nie ganz übereinstimmt), testet etwas und wirft es zum Betrieb. Der Betrieb fragt: “Wie sollen wir das betreiben?” Und irgendwie, mit grossem Aufwand, bringen sie es zum Laufen. Dann sieht der Kunde das Ergebnis und sagt: “Was ist das? Das haben wir nicht bestellt.”
Warum wird Security immer noch am Ende des Entwicklungsprozesses angeflanscht — und wie können wir sie nach vorn verschieben, ohne die Teams auszubremsen? In Teil 1 unserer GitLab DevSecOps Serie legen Patrick Steger und ich die Grundlage: Was GitLab ist, was Shift Left wirklich bedeutet und welche CI/CD-Konzepte man verstanden haben muss, bevor man eine DevSecOps-Pipeline bauen kann, die in der Praxis funktioniert.
Release on Demand ist der letzte Schritt in der SAFe for DevOps Continuous Delivery Pipeline, und es ist der Schritt, der alles zusammenführt. In diesem Video erkläre ich, wie Release on Demand funktioniert, warum die Trennung von Deployment und Release so wirkungsvoll ist und wie die gesamte Pipeline Organisationen befähigt, das Richtige richtig zu bauen.
Feature Toggles sind eines dieser Konzepte, die auf den ersten Blick einfach klingen, aber in der Praxis enormes Potenzial entfalten. In dieser Session des DevOps Meetup Zürich spreche ich gemeinsam mit Ben Rometsch, dem Gründer von Flagsmith, über das Was, Warum und Wie von Feature Toggles. Wir behandeln die grundlegenden CI/CD-Konzepte, die Feature Toggles notwendig machen, den Unterschied zwischen Deployment und Release, und wie moderne Feature-Flagging-Plattformen progressive Rollouts, User-Segmentierung und A/B Testing ermöglichen.
Nachdem wir ein neues Feature für unsere Nutzer freigegeben haben, müssen wir sicherstellen, dass alles reibungslos läuft. Stabilize ist die Aktivität im SAFe DevOps Health Radar, die sich auf die Aufrechterhaltung eines hohen Niveaus an Geschäftskontinuität konzentriert, damit wir unseren Kunden kontinuierlich Mehrwert liefern können. In diesem Video erkläre ich, was Stabilize umfasst und warum es für eine stabile, widerstandsfähige Produktionsumgebung unverzichtbar ist.
Release ist einer der letzten Schritte im SAFe for DevOps Health Radar. Zu diesem Zeitpunkt ist die neue Funktionalität bereits in der Produktion deployed und verifiziert. Jetzt ist es an der Zeit, die neue Funktionalität einer kleinen Gruppe von Nutzern oder allen Nutzern zugänglich zu machen. In diesem Video erkläre ich, was der Release-Schritt umfasst und warum er eine entscheidende Geschäftsentscheidung ist.
In diesem Artikel erkläre ich, was Continuous Deployment innerhalb des SAFe® DevOps Health Radars ist und warum es für die schnelle und sichere Wertlieferung unverzichtbar ist. Bitte beachten Sie, dass alles hier Besprochene unter der Lizenz von Scaled Agile steht und dass das Scaled Agile Framework als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.
Wie erkennt und behebt man proaktiv Produktionsprobleme, bevor sie zu einer Geschäftsunterbrechung führen? Respond ist die Aktivität im SAFe DevOps Health Radar, die genau diese Frage beantwortet. In diesem Video erkläre ich, was Respond umfasst und warum es für die Aufrechterhaltung einer stabilen Produktionsumgebung unverzichtbar ist.
Sobald unsere Features in der Produktion deployed und verifiziert sind, müssen wir genau beobachten, wie sie sich verhalten. Monitor ist die Aktivität im SAFe DevOps Health Radar, die sich darauf konzentriert, Systemleistung, Endnutzerverhalten, Incidents und den Geschäftswert zu verfolgen. In diesem Video erkläre ich, was Monitoring umfasst und warum es für die richtigen Entscheidungen über unsere Features unverzichtbar ist.
In diesem Artikel erfahren Sie, was genau der SAFe® DevOps Health Radar ist und wofür Sie ihn einsetzen können.
Der DevOps Health Radar ist ein Assessment, um Ihren aktuellen Stand zu bewerten und herauszufinden, wo Sie sich momentan in Bezug auf DevOps befinden. Er besteht aus vier Dimensionen: Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand. Jede dieser Dimensionen umfasst wiederum vier Aktivitäten. Bei Continuous Exploration sind das beispielsweise Hypothesize, Collaborate, Research & Architect und Synthesize.
