CI/CD on the Edge — Part3
System Design: Jenkins, PlatformIO, and more
To deliver a practical CI/CD mechanism at the edge of the network, a system design providing cost efficiency, maintainability, and scalability is crucial. The undertaking, high-level, objective is to find a way to implement Continuous Integration and Continuous Deployment pipeline for edge software development which has the possibility of being used by multiple projects. Worth mentioning, although a similar design could be used for production purposes, for the purpose of this article the system design has been kept simple.
The project code can reside on a DVCS like GitHub, GitLab, or BitBucket which can be chosen according to ones’ need. The orchestrator is hosted on a server (any server or cloud provider could be used), with access to the library and project repositories. The edge gateway shown in the figure could be an SBC like Beaglebone or RaspberryPi which have their own operating system (e.g. ARM Linux). The gateway is an edge device that can be an SoC (eg: ESP-32).
Orchestrator
Jenkins
Jenkins is one of the oldest, open-source, orchestrator’s available and therefore enjoys a plethora of features and huge plugin support. It supports various CVCS’s and DVCS’s, including AccuRev, CVS, Subversion, Git, Mercurial, Perforce, TD/OMS, ClearCase, and RTC, and can execute arbitrary shell scripts and Windows batch commands [18]. Builds can be triggered by various means, for example by commit in a version control system, by scheduling via a cron-like mechanism, and by requesting a specific build URL. It can also be triggered after the other builds in the queue have completed [18].
Travis CI (as an alternative)
Travis CI is one of the recent, open-source, orchestrator available. Out of the box support is available for GitHub and Bitbucket but not GitLab. PlatformIO, supports Travis CI by default. Implementation could also be carried out using Travis CI since it does not require any self-hosting for this implementation and could be beneficial for projects which do not intend to opt for PaaS but rather Pipeline as a Code.
Edge Testing
This is the second, but the most important stage to be addressed as part of this solution. The intention here is to find a tool that could be included as part of the CI-CD toolchain and be compatible with an orchestrator. The requirements for choosing the tool are:
1. The tool must be compatible with an orchestrator.
2. The tool must be able to run tests on-device.
3. The tool must be compatible with multiple boards and frameworks.
On-Device Testing
After ruling out device-specific simulators like BEAGLEBK and AdafruitIO, connecting an orchestrator with the actual device and running tests on the device via it is considered. Taking inspiration from one of the papers [15] (see part 2), Plank unit testing framework is considered to create tests and to run them via an orchestrator. This is still a tightly coupled solution and would require the devices to be connected physically to the orchestrator and the framework is limited in its coverage as well.
Jumper.io
Jumper.io is an open-source software that lets the user add their firmware to the virtual device. Jumper labs provides support for the simulator use as well. It is possible to write test scenarios with input to sensors and communication channels and read output via UART and GIPO. It has a possibility of integration with multiple orchestrators. But, it has limited support as far as MCU’s and peripheral device support is concerned.
Simics®
Simics® is another alternative that is considered. It is a simulator which, according to Wind River® [19]:
1. works well for 80% of the testing.
2. does not model bus protocols.
3. can save states as checkpoints.
4. increases flexibility and ensures consistency.
Although used by organizations like NASA and Toshiba, this is not open source and also it is a simulator and does not execute tests on the actual device.
PlatformIO
The search for a tool that could facilitate on-device testing comes to an end with PlatformIO. It is applicable throughout the phases of CI and CD. It is a one-stop-shop for all the challenges that were discussed previously. Some of the features of the tool, which make it an ideal fit are:
- While PlatformIO itself is a console application, it can be used in combination with one’s favorite Cloud Desktop IDE.
- It is independent of the platform, in which it is running. In fact, the only requirement is Python, which exists pretty much everywhere.
- It is open-source and supports 34 platforms, 20 frameworks, and 788 boards with support for over 7000 libraries for development.
- There is extensive documentation available as far as various implementations and integration are concerned. The documentation of setup and integrations can be accessed here [20].
- It has support for connecting with Jenkins and other leading orchestrators including TravisCI and native GitLab pipelines.
- The possibility of accessing the devices remotely, using agents and runners, exists.
- During development, support for library management exists, while the unified debugger makes life easier when trying to find bugs.
- It is possible to have multiple configurations based on varied devices and device types and use them during CI and CD processes.
References
[18] New adventures in software, Apr 2020. [online] https://blog.dandyer.co.uk/2008/05/09/
why-are-you-still-not-using-hudson/ accessed 10-04-2020.[19] Wind river simics, Mar 2020. [online] https://www.windriver.com/products/product-overviews/Wind-River-Simics_Product-Overview/ accessed 09-Mar-2020.[20] Platformio is a new generation ecosystem for embedded development, Mar 2020. [online] https://docs.platformio.org/en/latest/ accessed 09-Mar-2020.
Note: For the purpose of this article, the word “embedded” has been interchangeably used with “edge”
DISCLAIMER: This post only reflects the author’s personal opinion, not any other organization’s. This is not official advice. The author is not responsible for any decisions that readers choose to make.
