shorthen_rnd_time-ci_for_embedded_1 copy

Why using continuous integration in IoT and embedded software?

Software development and testing are two of the most important and time-consuming tasks in the creation of an embedded system. Embedded systems in the IoT space demand even more testing and quality assurance as these systems are distributed, connected, updated over the air and prone to security breaches. As market demand to shorten the development time from ideation to mass production increases, the embedded software development team is becoming overwhelmed with challenges like never before. The embedded industry, specifically in IoT, has realized that one of the ways of dealing with these challenges is to apply continuous integration processes — unit tests, early integration tests and automated testing. While continuous integration is in wide use in web and mobile development; this is not the case in the embedded software development. In embedded systems, the physical device with all its constraints makes continuous integration and test automation cumbersome.

In this series of posts, I’m going to explore different methods that can help shorten development time. These posts will be focused on streamlining and enabling continuous integration processes for embedded software development, including examples. If you are not familiar with the continuous integration process, I encourage you to learn about it if you want to ship high-quality code, faster.

How does continuous integration look like in embedded software development?

The diagram below is a simple illustration of a continuous integration process for embedded systems. What makes CI for embedded systems different is the physical device the software runs on.

Continuous integration in embedded software flow

The continuous integration lifecycle in embedded software development advocates to:

  1. Commit changes regularly to a source control repository.
  2. Build and integrate the software automatically at least once a day (recommended: after every code submission).
  3. Test the software automatically after a build is done. Either on the physical device/system or on a testing machine.
  4. Automatically test the software on the target physical device.
  5. Deploy.
  6. Analyze the report after each stage.

Note that a proper continuous integration process and automated software testing enables embedded software developers to work on different part of the system and code base simultaneously. When each commit triggers regression software tests, you get feedback as early as possible and fix bugs before it cost you with too many resources.

There are many available continuous integration tools, but none were built for embedded software development.

How to choose the right continuous integration tool for your embedded software team?

When comparing CI tools, you’ll find the following parameters:

  1. Cloud-hosted/Self-Hosted — portability and flexibility.
  2. License type.
  3. Integrations and plugins to IDEs, source control systems, cloud services, project management tools and more.
  4. Developed language
  5. Supported platforms
  6. Notifications
  7. Dashboard and release process visualization

Among the popular CI tools out there you can find — Jenkins, Buildbot, Travis CI, Circle CI, TeamCity, VSTS/TFS by Microsoft, GitLab CI and more. But as the web is full of CI tools comparisons and recommendations, I will only outline the ones that work for embedded software development (in my opinion, feel free to comment).

What do you need to consider for Continuous Integration in embedded?

In embedded software testing, you always need to adapt something to support your unique setup, so first and foremost the CI tool you want to use for embedded software must be modular, granular and easily integrated with different toolchains.

Apart from the CI tool, as testing is done on a physical device, you need to take into account that:

  1. The testing pipeline might get too long.
  2. Executing automated tests “on device” requires tailored hardware lab and integration to the CI tool.
  3. Running efficient unit, integration and system tests requires executing your code an x86 machine.
  4. Running regression tests after every commit might not be feasible (although recommended).

On the next series of posts, we’ll get to the details of continuous integration in embedded software.