Embedded and IoT devices are becoming increasingly popular in today’s world. These devices are used in various industries, such as healthcare, manufacturing, consumer goods and home automation. Ensuring the quality of these devices is crucial to ensure their reliability, safety, and functionality. But how to do that?
After we finished the GitLab DevSecOps series, Patrick changed jobs — and his new team is on GitHub. The problem is the same: no security checks during development. The platform is different. In Part 1 of our GitHub DevSecOps series, we cover what GitHub is, the CI/CD vocabulary you have to share before any pipeline conversation works, and the shape of the DevSecOps pipeline we will build over the next sessions.
Why does security still get bolted on at the end of the development process, and how do we move it earlier without slowing teams down? In Part 1 of our GitLab DevSecOps series, Patrick Steger and I set the stage: what GitLab is, what shifting security left really means, and which CI/CD concepts you have to understand before you can build a DevSecOps pipeline that actually works.
Over the past few years I have published a deep-dive on every single activity in the SAFe DevOps Health Radar. This post is the round-the-radar tour: a single page that walks you through all four aspects and all sixteen stages, with the original video for each and a link to the full article. Use it as a map — to find your starting point, to share with your team, or to assess where you are today and where you want to go next.
In this article, I explain what Test End to End means within the SAFe® DevOps Health Radar and why it is essential for delivering high-quality software. Please note that everything discussed here is under the license of Scaled Agile, and that the Scaled Agile Framework is a framework to be used as a toolbox. Take out what fits your needs or what solves your problem.
Build is the step in the SAFe for DevOps Health Radar where committed code is continuously integrated, tested, and turned into a deployable artifact with built-in quality. In this video, I walk through what the Build step involves, why continuous integration matters, and how techniques like gated commits and static security analysis help you maintain quality at speed.
In traditional software development, software is merged and tested by all developers in one big single integration step that usually takes weeks or even months. Since this only happens every few months, this step is very time-consuming.
In traditional software development, integration was a single, painful event. Every developer worked in isolation for weeks or months, and at the end the team merged everything in one big bang. The integration step took weeks, sometimes months. Conflicts piled up, bugs hid in the seams between modules, and nobody could say with confidence whether the system actually worked. Continuous Integration was invented to make that pain disappear.
A value stream is the path that value takes from the first idea all the way into production. It is the sum of every step, handover, and wait in between. In this video, I walk through a simple seven-step approach for identifying a value stream, measuring how it really performs, designing a target state, and then improving it step by step. The numbers in the example are simplified on purpose, so the method shines through more clearly than any single result.
