If you’re in a leading position and responsible for embedded systems, you have probably already heard a lot about Continuous Delivery.

The benefits are obvious; like quality gains and being able to do releases on a next to daily basis.

At the same time, it’s not that easy to set up the organization, the routines and the mechanics necessary in order to do CD.

Even if CD is a hot concept there are few that has actually brought it into practice. Mostly because /they don’t know how to get started/it can be difficult to get started.

In this article we’ll cover a great way to get started with CD – by setting up a small-scale experiment.

Before you start

As with most things in life, you need to figure out a good reason to why you want your team to do Continuous Delivery. There are many valid reasons, but I think these are the most impactful. Give it a thought and figure out which ones are the most important for your organization. This is important in order to know how to scope your first test.
Since the big benefits for your product and organization are still a way off at this time, I would suggest thinking from your developer’s perspective. Most developers like to have a code that is in good health and they like to work proactively with keeping it in good shape. To shape your arguments about getting started around this is also a great way to get people on board.

Scoping your first test

A great way to start with CD is to run a first test. And in order to get a good test you should build a complete chain of automated testing and release. Include all the stages that you would like in an ideal world where everything is fully automated. This way you and your organization will get a real taste of what CD can do for you.

This said, it is effective to limit the test to only one module, a small and isolated module that has been around for a while. This allows you to focus on testing the process rather than fixing the code of your module.

The Basic Continuous Delivery process

The basic Continuous Delivery process consists of four steps that you need to implement. This is an overview of these steps and you can dive as deep as you want in any of them, but the focus here is to get started.

This suggestion is with simple tools that your developers can do on their own without the need to set up servers and all that bother.


You probably already have a version control tool like GIT? You probably also have rules that say that main should always work and build without errors? An easy way to make sure that this is the case is to have a script called Delivery Check. This script should be run before you check in your changes.

I like to do this script in python, but whatever scripting tools you use will work fine.

That is basically the first step, create a script that you run before you commit your changes and the output from the script should tell you if it is ok to commit your changes.


The most important part of the delivery check script is to have it run the build command. The script should call your build tool the same way you do from your IDE or in your CI server.

This makes sure the code is built in the exact same way all the time and the output should still be that your code is good to go for check-in or not.


When your script is up and running the build, you can expand it with unit tests or static tests.

The goal is the same, to have the script tell the developer that the changes are good to go. After this step the code builds ok and the changes are tested. That means that it is good to check-in.

Voila! You have created a first small scale test of CD! The first test shouldn’t be bigger than that. I expect that most developers should have a basic version of the Delivery Check up and running within a couple of days.

The next step

One way to continue is to start adding tests for more modules, this way you can build the tests for all the modules without setting up any servers. But I recommend starting automating things now.

You can start looking at tools like Jenkins to run the scripts for you, and then connect more tools as you need them.
More on this topic
This is a great way to start; I have no doubt about that. The logical next step would be to add a second module, a third and so on. However, when doing this you will inevitably run into scaling problems.

When deciding to try it out there is no need to think about the demands on infrastructure though. Nor about how to merge multiple teams working on the same product or how to ensure the integrity of the whole process.

Our recommendation thus is to start small but with all the stages. That way you get data quickly and will be able to evaluate the potential of continuous delivery for your business.

Scaling will be the topic of future articles. Download our report “Continuous delivery for Embedded Systems – how to get started” and you will get an email notice when there’s more on this subject.

Have fun!