DevOps is a mindset

DevOps methods taken to the automotive industry

by Sebastian Sucker | April 3, 2018

“You build it, you run it” is not a philosophy that can easily be taken to non web tech industries. This harsh reality is something we ran into while making our journey through the automotive industry. But if we cannot duplicate this philosophy outside of our web tech bubble, maybe it’s possible to create a mentality that at least supports the feeling of responsibility for every line of code that eventually finds its way into a product. In our case it ends up in a car.

A different mindset in non web tech industries is mostly due to scaling. Projects may have up to 100 developers which only have a limited access and are not necessarily testing their changes against changes from other teams. On the “other side” there are some people that need to integrate code they did not write themselves into code they did not write either. If they encounter problems they play a game of ping-pong until it works. These teams can end up being the bottleneck, a frustrating situation to be in. For us, this bottleneck felt like a wall between DEVs and Integrators.


To get better results and avoid the bottleneck situations, this setup needs to change. Developers need to have responsiblity for the code. They need to be able to integrate with other software components by themselves, test it, see it in action. Handing over that task in a manual way to the Dev teams is not a solution. It is very hard for one developer to know the big picture, dependencies of other components and the way everything gets integrated and tested against each other.

Automation is the way to tackle this isssue. A fully automated chain of actions enables everyone in the project to create and see the bigger picture. In a fully automated chain, 1 line of code change in a small module triggers a buildchain. Build, Test, Pre-Integration, Artifact, Flash to device and Acceptance tests can be run without the developer having to initiate them or needing deeper knowledge about them. The developer receives a mail saying “works!” and that is that. This doesn’t just increase velocity and quality but most importantly eliminates the “single point of failure” role of the integrators.


By eliminating that clear line between “us” and “them” we are creating a synergy that has many advantages. Advantages that we need to communicate.

If we want to achieve as much as possible in less time, it’s necessary to make all project members understand the value of the automation. To bring everyone on board we started preaching: Developers as well as Integrators should rely on the automation as a tool to make their work simpler. Quality Assurance teams can gain insight and reports on per commit basis. Project Managers get the higher quality & velocity they always ask for.

To establish and stabilize this mindest we need to create communities of interest. People need to talk to each other - the chat in the kitchen can create synergy by sharing experience about test failures and how to fix them. Chat channels for build, test & integration create visibility about what’s going on outside my module and make teams be able to fix problems during the development cycle. People should feel less like a Code Monkey and more part of one team, one project, something great.

It is possible to make software engineering in the automotive industry work in a way similar to how DevOps teams in the whole world work if they alter some processes and mindsets. They can achieve the same benefits from it and will feel more productive and challenged.