Software Composition Analysis kümmert sich um die Bibliotheken, die du einbindest. Aber was ist mit dem Code, den dein Team selbst schreibt? Genau dafür ist Static Application Security Testing da. In Teil 5 unserer GitLab DevSecOps Serie integrieren Patrick Steger und ich SAST in die Pipeline, bauen ein paar realistische Schwachstellen in unser Spring-Boot-Beispiel ein und schauen zu, wie GitLab sie aufgreift.
Du lieferst eine Java-Anwendung aus, die von Spring Boot abhängt, das wiederum von dutzenden weiteren Bibliotheken abhängt — jede mit ihrer eigenen Lizenz. Und die meisten Teams können dir nicht sagen, welche Lizenzen das eigentlich sind. In Teil 4 unserer GitLab DevSecOps Serie ergänzen Patrick Steger und ich die Pipeline um License Compliance, sodass diese Frage bei jedem Commit automatisch beantwortet wird. Die gute Nachricht: Mit GitLab Ultimate ist das eine Template-Zeile.
Dein Code ist der kleine Teil. Die Libraries, die du reinziehst, sind der grosse Teil — und genau dort steckt der Grossteil deiner CVEs. In Teil 3 der GitLab DevSecOps Serie bauen Patrick Steger und ich eine kleine Spring-Boot-Demo auf, hängen sie in eine GitLab-Pipeline und ergänzen anschliessend Software Composition Analysis mit einer einzigen Include-Zeile.
Bevor wir irgendwelche Security-Checks nach links verschieben können, brauchen wir ein Projekt, ein Repository und eine Pipeline, die tatsächlich etwas baut. In Teil 2 unserer GitLab DevSecOps Serie loggen sich Patrick Steger und ich in GitLab ein, legen ein neues .NET-Core-Projekt aus einem Template an und schauen uns die .gitlab-ci.yml an, die GitLab automatisch für uns generiert — inklusive Build- und Test-Job, die das Fundament für alles werden, was wir später ergänzen.
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.
Wie stellt man sicher, dass die eigene Organisation nicht mit zu vielen Projekten, zu vielen Ideen und zu wenig Fokus überlastet wird? Und wie stellt man sicher, dass man das Richtige baut? Genau dafür gibt es Epics. In diesem Video erkläre ich das Konzept der Epics, zeige ein konkretes Beispiel und erläutere, warum Epics deutlich effektiver sind als traditionelle Projekte.
Hast du dich jemals gefragt, was “DevOps Engineers” eigentlich tun? Was bedeutet “DevOps” überhaupt? Dieser Blogbeitrag soll das Konzept von DevOps erklären und den Wert aufzeigen, den es einer Organisation bringt.
In den letzten Jahren habe ich zu jeder einzelnen Aktivität im SAFe DevOps Health Radar einen Deep-Dive veröffentlicht. Dieser Beitrag ist die Tour rund um den Radar: eine einzige Seite, die Sie durch alle vier Aspekte und alle sechzehn Stages führt, mit dem Originalvideo zu jeder Aktivität und einem Link zum vollständigen Artikel. Nutzen Sie ihn als Karte — um Ihren Einstiegspunkt zu finden, um ihn mit Ihrem Team zu teilen oder um zu bewerten, wo Sie heute stehen und wohin Sie als nächstes wollen.
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.
Das SAFe® for DevOps Training ist ein Assessment oder ein Workshop, der ideal für Teams geeignet ist. Warum? Weil der Fokus darauf liegt, den Wertstrom dieser Teams voranzutreiben. Indem wir Fragen, Herausforderungen und mögliche Hindernisse adressieren, können wir am Training arbeiten, um ihnen Mehrwert zu bieten. Wir geben den Teams den Theorie-Input, was DevOps genau ist.
Learn ist der letzte Schritt des SAFe for DevOps Health Radar, und in vielerlei Hinsicht der wichtigste. Hier treffen wir die schwierigen Entscheidungen darüber, wo wir investieren, wo wir aufhören und wie wir alles, was wir tun, kontinuierlich verbessern. In diesem Video erkläre ich, was der Learn-Schritt umfasst und warum er der Schlüssel ist, um das Richtige richtig zu bauen.
