Smarter devices, smarter development: CI/CD for embedded systems
Dive into the world of embedded device development, where Trunk Based Development and Deploy or Die aren't just buzzwords but essential methodologies that promise early deployments, seamless collaboration, interoperability, and fierce security.
Continuous Integration and Continuous Deployment (CI/CD) are tattooed on the chest of every software engineer in our house. And when it comes to working on embedded devices, we bring the same enthusiasm. We fill in CI/CD using Trunk Based Development and Deploy or Die.
So why do we love this combination so much when it comes to embedded device development? Let's find out.
Deploy Early, Deploy Often
Deploy or Die doubles down on our commitment to deploy early and often to validate assumptions and enhance value. We use Trunk Based Development to integrate all code into a single pipeline, encompassing applications to drivers. This way we create a cohesive system that's continuously tested with new features.
This approach ensures that the system is always ready for release, contributing to our goal of maximising value through frequent deployments.
Interoperability and Immediate Feedback
Besides that, this combination fosters collaboration between application and driver developers. The automated testing of application code with the latest driver software, and vice versa, provides immediate feedback on the behaviour of the entire system and ensures interoperability is maintained. This not only benefits our developers but also our Quality Assurance experts and our users in the end.
Testing Physical Interfaces
Of course, when working with embedded devices, you often come across physical interactions, such as pushing a button, simulating a power loss or inserting a USB stick. This naturally requires another layer of testability.
So to make this process testable, we integrate single board computers (SBCs) with relay switches into our CI/CD setup by installing GitLab runners on them. These SBCs allow us to control physical actions and test over-the-air (OTA) update mechanisms, ensuring comprehensive testing of all deployment methods.
Managing Hardware Upgrades
As projects progress, hardware upgrades become inevitable. If the difference in hardware is manageable in your code by conditional checks, it's possible to keep using a single pipeline with a single set of artefacts for development and production.
But at some point, the compatibility will be too costly to maintain. Once the old hardware becomes too costly to maintain in the latest version of your product, it might be wise to branch off a separate software version for the new hardware. Although this results in separate pipelines, each with its own set of artefacts, it allows for specialised code targeting specific hardware.
Secure CI/CD Processes:
Security for embedded devices is handled by their Public Key Infrastructure (PKI). Maintaining this security in CI/CD processes is crucial, especially when dealing with production environments. To achieve this, it is essential to keep the PKI of development devices separate from production devices.
By maintaining separate certificate authorities and chains of trust for each environment, we empower developers to deploy OTA updates on development devices without compromising the security of the production fleet.
In conclusion
We believe Trunk Based Development and Deploy or Die are great approaches to embedded device development. By emphasising early and frequent deployments, fostering collaboration between developers, and implementing robust testing methodologies, we are advancing towards a more efficient and secure development process. Our commitment to these approaches remains at the core of our way of working - even when the product becomes more and more complex.