Nachdem wir die GitLab DevSecOps Serie abgeschlossen haben, hat Patrick den Job gewechselt — und sein neues Team arbeitet mit GitHub. Das Problem ist dasselbe: keine Security-Checks während der Entwicklung. Die Plattform ist eine andere. In Teil 1 unserer GitHub DevSecOps Serie zeigen wir, was GitHub ist, welches CI/CD-Vokabular man teilen muss, bevor irgendein Pipeline-Gespräch funktioniert, und wie die DevSecOps-Pipeline aussieht, die wir in den nächsten Sessions aufbauen werden.
DevOps-Trends 2023
Wir werfen einen kurzen Blick auf meine Prognosen für 2021 und 2022, bevor wir uns den Schwierigkeiten zuwenden, mit denen Unternehmen bereits konfrontiert sind. Aufgrund von Silo-Organisationen findet zwischen den verschiedenen Organisationsbereichen kaum Koordination statt, und Unternehmen planen weiterhin Jahresprojekte statt Produkte. Daher müssen Unternehmen einige DevOps-Methoden oder -Trends übernehmen. DevOps ist ein Mindset, eine Kultur mit technischen Praktiken, die alle Menschen entlang des Value Streams ausrichtet, um dem Kunden kontinuierlich Wert zu liefern. Zu den Top-DevOps-Trends für 2023 gehören das Bauen von Produkten, der Betrieb des Produkts, die Sicherstellung der Produktqualität, die Überwachung des Produkts, die Organisation entlang des Value Streams, das Ermöglichen von DevOps in Produktteams und die Industrialisierung der gesamten Produktentwicklung.
Zwei Jahre Trend-Prognosen später hat sich die DevOps-Diskussion verschoben. 2021 ging es um Adoption. 2022 haben wir die Trends auf den Adoption Lifecycle gelegt. 2023 ist die nützlichste Brille der Value Stream: wie Produkte gebaut, betrieben, qualitätsgesichert, monitort, organisiert, enabled und industrialisiert werden — End-to-End. Die meisten Organisationen leiden immer noch unter Silos und projektbasierter Jahresplanung. Die Trends 2023 schliessen genau diese Lücken.
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.
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.
Nach elf Sessions, in denen wir eine komplette DevSecOps-Pipeline mit GitLab aufgebaut haben — von Software Composition Analysis über Container Scanning, SAST, Secret Detection und DAST bis hin zu Merge Request Integration und Scheduled Pipelines — schliessen Patrick Steger und ich die Serie mit unseren Empfehlungen ab. Was funktioniert, wo es Stolpersteine gab und was wir jedem mitgeben würden, der heute die gleiche Pipeline aufbauen will.
In zehn Sessions haben wir sechs Security-Tools in eine GitLab-Pipeline verdrahtet, die auf jedem Commit und jedem Merge Request feuert. Sind wir damit fertig? Nicht ganz. Code, der in Produktion läuft, bleibt dort Wochen oder Monate liegen, und in dieser Zeit finden Security-Researcher laufend neue CVEs in genau den Dependencies, die du längst ausgeliefert hast. In Teil 11 der GitLab DevSecOps Serie bauen Patrick Steger und ich eine Scheduled Pipeline, die den Production-Branch automatisch erneut scannt — ohne dass jemand pushen muss.
In den vorherigen neun Sessions haben Patrick Steger und ich eine GitLab DevSecOps-Pipeline gebaut, die SAST, Secret Detection, Software Composition Analysis, Container Scanning und DAST ausführt. Nützlich — aber nur dann, wenn sie Probleme tatsächlich findet, bevor der Code im Default-Branch landet. In Teil 10 schliessen wir diesen Loop: Wir hängen die Pipeline an Merge Requests, sodass jede Änderung gescannt wird, die Deltas gegen den Default-Branch sichtbar sind, und Freigaben erforderlich werden, wenn neue High- oder Critical-Vulnerabilities auftauchen.
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.”
Nach acht Sessions, in denen wir Scanner in unsere GitLab-Pipeline eingebaut haben — SAST, Secret Detection, SCA, License Compliance, Container Scanning, DAST — haben wir jetzt ein anderes Problem. Wir haben hunderte von Vulnerability-Findings. In Teil 9 schauen Patrick Steger und ich uns das eingebaute Vulnerability Management von GitLab an: was es liefert, wo es schwächelt und wie man Findings tatsächlich triagiert, ohne den Überblick zu verlieren.
Alles, was wir bisher in der GitLab DevSecOps Pipeline gemacht haben, war statisch — Analyse von Source Code, Dependencies, Containern und Konfiguration. In Teil 8 überschreiten Patrick Steger und ich die Linie zu Continuous Delivery und ergänzen Dynamic Application Security Testing. DAST heisst: Wir deployen die Anwendung, starten sie und greifen sie von aussen mit einem automatisierten Penetration-Testing-Tool an. GitLab liefert das Feature out of the box mit OWASP ZAP.
