by Sebastian Sucker | October 10, 2017
Endocode usually supports companies that already work in a DevOps mode or are at least planning to do so. The automotive industry is different. Companies active in this sector have a long history in designing & building hardware as well as software - which is what they are really good in. Buzzwordy topics like DevOps, CI/CD and others are not something they really care about.
But things tend to change. The complexity of software systems running on embedded devices in cars is increasing immensely. More and more sensors & actors need to get hooked up and feed into the cars brain. Features like autonomous driving, driving assistance or automated parking become more important. Imagine just leaving your car in the parking lot, hitting a button on your phone and the car will find and take a spot.
This increasing complexity needs to be handled somehow. Automotive suppliers are doing a great job at implementing the features but integrating all the different components is challenging. As always there is a bottleneck somewhere which, in this case, is the testing & integration of all the different software components.
To add to that, client demands are getting tougher. Release cycles reduced from several months to some weeks are upcoming requirements. If you want to deliver faster and more reliable to the customer the projects need some changes.
This sounds similar to a lot of problems people wanted to solve by applying agile and DevOps methods to their development processes in the past already. Goals are increasing velocity, decrease reaction times and cycles as well as maintaining compliance. We helped by combining our experience from the DevOps world with the automotive processes.
This is challenging of course. Approaches like continuous integration rely on tools and methods that are common in the web application development world or in the Open Source development scene. It is for example way easier to run an acceptance test that only requires a user & a browser than running a test with an embedded device, some sensors & other special hardware - in a car, on a motorway, at 200km/h.
This series of blog posts should give an introduction on how “old-fashioned” industries can benefit from the DevOps movements and its methods, tools and processes. Here is a short preview of the topics we will be covering in this blog post series:
DevOps is a mindset
By simplifying the integration process every developer should be able to build a release, integrate their change into the current codebase and see the results in action. That changes the mindset from “throwing code over the wall” to “I am responsible for my stuff”.
Achieving release cycles like that could only be done with a lot of automation as integrators are rare and their time is limited. We needed to automate:
- Unit & module tests
- Static code analysis
- Integration environments
- Pre-Integration checks
- Management reports
- Infrastructure automation
- other analysis tools
- Smoke testing
We had to start somewhere, so we will do the same thing here by starting with …
Processes are very important for software engineering in the automotive industry as every line of code can potentially harm people. Approaches like “Automotive SPICE” are made to ensure a high level of quality and compliance.
As usual compliance and velocity are not going hand in hand by default. We wanted to make sure we reach the required quality criteria as well as speeding up the process. To achieve this, we focused on a few improvements.
The creation of artefacts on a dedicated machine is one example where process improvements can ensure a reliable and reproducible state. Apart from ensuring compliancy, it also makes it obsolete to wait for builds to finish.
Integration processes (especially if there are more than 1 party involved) are very complex and error prone. Automated, simplified and properly documented processes reduce the risk significantly.
Testing processes need to be refined. Manual tests are necessary but should only be used if no automation is possible. To have a reliable way of testing the whole software stack it should be automated and generalized as much as possible.
It’s critical for all the included teams to know what is going on. This can easily be done with dashboards on TVs hooked up on the wall showing build status & tickets, creating reports from Jenkins, sending mails for builds, etc.
In the early days it was pretty hard for QA team members to know the build status or test status of a software component. In some cases they were not even able to create them themselves.
Next generation tools
Tools like Serena Dimensions or Microfocus Starteam are used widely in the industry even though there are a lot of (Open Source) alternatives. Minimized vendor lock in and large communities that support the development of the projects are arguments that should be considered while choosing an automation tool. Endocode is focused on Open Source solutions and can therefore provide expertise with support & training on various solutions that are interesting for the automotive industry like GIT, Jenkins, CHEF and more.
So this is how we started. Let’s go into details and look into DevOps is a mindset