What you need to know for CI/CD for the IoT.

CI/CD is a development method for delivering software solutions in a safe, reliable and regular manner. It involves a continuous and automatic process for building, testing and deploying to meet a team’s code quality and software security standards. Traditionally when we talk about CI/CD, we think of deploying web or mobile apps, but CI/CD can also have a profound impact on developing IoT devices. In this blog, we will explore how CI/CD can benefit the IoT, the challenges faced by developers and how to overcome these challenges with a modern IoT approach to CI/CD.

What is CI/CD?

CI/CD is known as a DevOps (Development Operations) practise and combines two different techniques CI (Continuous Integration) and CD (Continuous Deployment). Continuous Integration is the process of automatically building and testing code. It involves the constant integration of small code changes to a shared code repository that tracks these changes and provides version control. The code is regularly and automatically built and tested. The result is a software package that is ready to be distributed across servers or devices.

What makes CI powerful is the ability to integrate all team members code together in a single system. Members can make contributions without fear of code conflicting or introducing more bugs. If errors are introduced, the system can detect them and alert the user before it is deployed live. Fixes can then be made quickly before bugs proliferate and become costly to fix.

Continuous Deployment is the technique of distributing the software package that has been created by the CI. It is rare for an application to only be run on a single device or server and instead must be distributed across multiple different environments. Continuous deployment automates this process where it is simple for developers to release new solutions and updates in minutes rather than manually releasing which could take days.

What is the IoT?

The Internet of Things is the concept of having devices connected through the internet to form a giant network. It can use sensors as input, communicate with other devices and interact with the external world. Everything from smart cameras through to refrigerators and automobiles are expected to become IoT devices. It is now forcing engineers to rethink how the electronics embedded in these devices, known as embedded systems, are being developed.

Traditionally, embedded systems were explicitly thought to have limited connections to other devices. Now, however, embedded systems are expected to become a distributed intelligence across the IoT. Embedded software engineers need to understand how their devices can securely receive, process and transmit information in a much larger network. This has put enormous strain on developers and teams that are expected to add the additional functionality of the IoT as well as deal with the added safety and security concerns.

How the IoT benefits from the CI/CD

By embracing CI/CD embedded developers can keep embedded system development on track due to:

More efficient development

One of the greatest benefit of CI/CD is that it can improve development speed and quality simultaneously which leads to cost savings. Using CI/CD encourages teams to work together and solves conflicts when their code is merged early. It makes finding and tracking bugs much faster and solves them at the beginning of the process rather than letting them slip into later stages of the process where they are much more expensive to solve.

Increased Safety

When we are concerned about safety, traceability is key. We need to know exactly what tests were run on what version of the code and who was responsible for that code. CI/CD provides that traceability in the form of logs that provide a step by step overview of how the project is evolving. Code and functional coverage are often used as safety targets and through CI/CD we can monitor the development of our devices to see how those goals are progressing.

Increased Security

Security is more of a concern than ever before. In the past IoT devices have been left unsecure with not even passwords to protect them. This is no longer an acceptable standard when it comes to the devices gathering data about our lives. CI/CD can include automated tasks for reviewing, auditing, scanning and testing for security issues.

The challenges of CI/CD and the IoT

The IoT is not only changing how we design embedded systems, but we are developing them as well. The connectivity of the IoT opens a wide range of possibilities for regular and fully automated builds and tests. However, there are fundamental differences between regular CI/CD used for deploying to web servers and CI/CD for the IoT. Building flows for the IoT is much more complex process because:

CI/CD tools are built with standard web server-based flows in mind. They give thousands of tutorials showing how to automate Javascript but provide little for embedded software. They do not provide the specific requirements needed for automating the IoT.
The development tools we use for the IoT often aren’t setup for automatic flows and can be difficult to script.
Setting up the same development environment across teams is more difficult.
Often safety and security requirements are much higher.
CI/CD encourages running many tests at once, but that increases the cost of embedded board farms.
The low computing power of these devices can make building and running tests slow
There is a plethora of different connections that be used in a flow such as JTAG, I2C and ethernet.
The hardware stack is complex. Projects may not just be focused on the software, but the firmware too. We are also seeing the IoT adopt more custom silicon chips, such as custom SoCs, ASICs and FPGAs. This hardware needs to be included in the flow as well to have a truly complete autonomous testing system.

CI/CD flows for the IoT

Figure

Before we look at how to solve the issues of using CI/CD for the IoT, let’s look at a standard CI/CD flow. Figure 1 shows a standard CI/CD flow for a web application. Code is taken from the version control system such as Git and placed on a staging server that performs the continuous integration. It will compile and test the code before packaging up for deployment. The package is then taken to the deployment servers to be run.

Figure 2

Figure 2 shows how we can modify that standard flow to meet the challenges of automating the IoT process:

Simulation and emulation. The first challenge we can overcome is dealing with the need for hundreds of hardware boards in our testing system. We also need to ensure that the team’s code is tested within the same clean environment. This can be done by simulating or emulating our hardware to form virtual platforms where hundreds of tests can be run. These virtual platforms form a single source of truth for developers to test from as well. To do this, code is taken from the version control system and cross compiled for our chosen IoT device. Our server then acts as a host machine for up to hundreds of virtual platforms, which can run the builds as if running on actual hardware. We can then encourage developers to keep building and testing without added expenditure.
On-device testing. Our second major challenge is effectively communicating with hardware boards that we want to our applications on to test with. On top of this, we need to be able to change anything on the device, not just the software, but the firmware and hardware too. This is a process known as hardware-in-the-loop (HIL) testing. The good news is that there are many effective methods for doing so. If we are just updating a software application on the device, we may be able to use protocols like SSH. If we are booting new firmware, we may need a connection via JTAG. What all of these have in common that is not used in standard CI/CD is the need to have a host server that is able to communicate with the device. The host server must provide the built files and then execute the program complete with any needed input data. That host must also be able to extract the logs and the results from the device to determine if the test passed or failed.

Why BeetleboxCI?

Many organisations are concerned about adopting CI/CD because they believe that the effort needed to develop a great CI/CD for the IoT will outweigh the benefits. If we are not careful, maintaining and managing the CI/CD can become a serious burden. BeetleboxCI is a CI/CD designed specifically to solve the development issues of the IoT and is simple enough for the entire team to use. Our solution is tool, software and connection agnostic, so it can be used automate your existing workflows. No additional software is needed to be installed on devices.

Conclusion

Thanks to the advancement of CI/CD tools, building automated flows for IoT has become far easier. Whilst a traditional CI/CD setup would consist of building, testing and deploying across web servers, IoT requires both virtual platforms and hardware in the loop testing. Using these techniques, we can overcome the issues of requiring large amount of hardware, whilst still being able to test across the entire hardware stack. By adopting CI/CD, IoT developers can enjoy increased security and safety as well as a more efficient development process.

If you would like to learn more about BeetleboxCI, watch our intro video here.

To get access please feel free to contact us here.