An der Conf42 DevSecOps 2024 Konferenz habe ich meinen Ansatz zur Architektur für Continuous Delivery vorgestellt. Nach über 21 Jahren bei Zühlke, in denen ich branchenübergreifend an DevOps-Transformationen gearbeitet habe, sehe ich immer wieder dasselbe fundamentale Problem: Wertströme, die durch Mauern der Verwirrung gebrochen werden. In diesem Vortrag zeige ich, wie Organisationen den Weg von Projekt-Denken zu Produkt-Denken schaffen, Qualität und Sicherheit von Anfang an einbauen, für Betreibbarkeit architekturieren und Platform Engineering zur Skalierung nutzen können.
Was definiert hochwertige Arbeit in der Softwareentwicklung? Ist es Scrum? Clean Code? TDD? Funktionale Programmierung? In dieser Expert Talks Session präsentieren mein Kollege Milan und ich zwei komplementäre Perspektiven. Milan behandelt die Säulen hochwertiger Engineering-Arbeit, von Teambildung und Kundenzentrierung bis zu Clean Code und Engineering-Kultur. Ich zeige dann, wie DevOps und Continuous Delivery helfen, grossartige Produkte zu bauen, indem man vom Projekt-Mindset zum Produkt-Mindset wechselt.
Ist DevOps wirklich der Grund dafür, dass Testing- und Quality-Assurance-Mitarbeitende (QA) zunehmend durch Automatisierung ihren Job verlieren? Pia Wiedermayer, Head of QA, und Romano Roth, Head of DevOps, diskutieren verschiedene Wege, den reichen Erfahrungsschatz von Testing- und QA-Spezialisten in die agile Teamkultur einzubringen.
Wenn wir über traditionelles Testen sprechen, meinen wir das V-Modell, das in Wasserfall-Projekten verwendet wird. Wir betreiben Requirements Engineering, schreiben Features für unsere Software nieder, brechen diese dann herunter und schreiben Stories, die anschliessend den Entwicklern zur Umsetzung übergeben werden. Der Entwickler setzt dies in Code um und schreibt dann Unit Tests und Integrationstests.
In der traditionellen Softwareentwicklung wird Software von allen Entwicklern in einem grossen einzigen Integrationsschritt zusammengeführt und getestet, der in der Regel Wochen oder gar Monate dauert. Da dies nur alle paar Monate passiert, ist dieser Schritt sehr zeitaufwändig.
In der klassischen Softwareentwicklung war Integration ein einziges, schmerzhaftes Ereignis. Jeder Entwickler arbeitete wochen- oder monatelang isoliert, und am Ende wurde alles in einem grossen Big Bang zusammengeführt. Dieser Integrationsschritt dauerte Wochen, manchmal Monate. Konflikte häuften sich an, Bugs versteckten sich in den Nahtstellen zwischen Modulen, und niemand konnte mit Sicherheit sagen, ob das System tatsächlich funktionierte. Continuous Integration wurde erfunden, um genau diesen Schmerz aufzulösen.
