CI/CD DevOps Setup for Projects using Zephyr RTOS

Training overview

The training is divided into 6 parts:

If you’re looking to level up your skills and learn how to setup full scale CI/CD process using Zephyr RTOS, then sign up for this code right now.

You will be able to implement the highly important continuous delivery process for your new firmware with confidence.

Below follows a more detailed description of each module.

Setting up repository

Setting up a repository correctly is a crucial step in any software project, and this section will guide you through the process from scratch. By setting up the repository from scratch, you’ll learn how the whole repository is set up for firmware development using Zephyr RTOS, and you’ll be able to customize it to your specific needs.

This section covers adding the required files, such as CMake files, Kconfig files, CODEOWNERS, gitignore, and more. These files are essential to the setup and configuration of your repository and help to ensure that everything is organized and structured correctly for an efficient CI/CD setup.

I will also show you how to add a pre-commit hook that will run checks on changed files before each commit, should you choose to do this. This is an important step to ensure that any changes made to the repository are thoroughly checked before they are committed. This helps to prevent any potential issues and ensures that your repository remains stable and reliable.

Finally, the section covers adding a repository init script that will set up the local repository and system after a checkout. This is an essential step to ensure that everything is set up correctly and that you can start working on your firmware without any issues.

Setting up GitLab CI

In the "Setting up GitLab CI" section, we’ll dive into configuring GitLab for effective CI/CD with Zephyr RTOS. With your repository set up, you’ll learn how to create a continuous integration pipeline using .gitlab-ci.yml file. I’ll also walk you through creation of Docker images that can be run locally through GitLab-runner which is useful during development.

Next, we’ll guide you through adding a merge request template, which will make it easier for developers to understand what’s expected of them when submitting code changes. We’ll also cover configuring your repository for trunk-based development, which is essential for effective continuous integration workflow that involves the whole team.

We will also look at checks we can add for merge request titles and a few other details.

Finally, we’ll add Zephyr compliance checking scripts that will enable you to verify the content of a merge request before merging it. This will ensure that all code changes comply with Zephyr guidelines, preventing any issues that may arise later on. We can reuse a lot of the existing Zephyr infrastructure in this way but adopt it to our own firmware project.

By the end of this section, you’ll have a GitLab CI/CD pipeline set up for continuous delivery.

Directory Structure

In the "Directory Structure" section of this course, we dive into the topic of organizing your project directory. We will be following Zephyr RTOS directory organization as much as possible but adjusting it to our standalone project needs. This will allow us to reuse a lot of existing Zephyr RTOS infrastructure for our own project as well.

After a GitLab pipeline set up, this step is crucial to ensure that your project is scalable and manageable in the long run.

We will start by adding the rest of the directory structure, including an example application that serves as a template for you to work from. We also cover adding a custom board so that you can build the application for your custom hardware. The next step is to add a CMake library directory, which will contain additional cmake scripts that we will be writing for our project.

We also add an example device driver to provide a template for device driver directories, as well as a documentation folder (which we will populate with documentation a bit later) and a global include directory for public interfaces of libraries and drivers visible across the whole firmware project. Additionally, we cover adding an example library so that you have a way of adding libraries shared between multiple applications.

Finally, we will add samples directory where we will be placing application samples for components that we will later be adding to our project. These samples will serve as minimal application which can be used for testing and demonstrating how to use features of our main firmware in isolation. We will use samples as standalone applications that only include a small portion of features helping us to decouple our firmware features effectively.

By the end of this section, you’ll have a solid understanding of how to organize your project directory effectively, making it easy to maintain, scale and manage in the long run. You’ll have added all the necessary components required for a successful Zephyr RTOS CI/CD setup, setting you up for success in your firmware development journey.

Documentation Generation

Once the full directory structure is in place, it’s time to focus on generating high-quality documentation for your firmware.

In this module, we will adopt the Zephyr documentation generator so that it works in an external repository - such as the repository where you have your firmware code. This involves moving the doc generator and adopting scripts so they build docs for your project. You’ll learn how to add robot framework scripts for verifying chapter structure to ensure that the documentation follows a roughly similar structure.

Linking the docs together is the next step. You’ll learn how to generate a single PDF or HTML output from your documentation, making it easier to read and share stakeholders and customers alike.

Lastly, we’ll cover adding the doc build process to CI and making everything pass all CI checks that we have set up earlier. This will help us ensure that our documentation is always up-to-date and of high quality.

By the end of this section, you’ll have a comprehensive understanding of how to generate high-quality documentation for your firmware using the Zephyr documentation generator. You’ll be able to generate a single PDF or HTML output, and you’ll know how to add the doc build process to CI to ensure that your documentation stays up-to-date.

Test Infrastructure

In the "Test Infrastructure" section of this course, we focus on the crucial aspect of testing. We cover the three main types of tests that need to be added to ensure that your firmware is reliable and meets set requirements: unit, integration, and system tests.

While Zephyr only provides limited support for unit tests and integration tests, I will provide you with the necessary tools in this section to add proper unit testing support using CMock. We start by adding Unity, a standardized testing framework that replaces ZTest, and we will then add CMock, which allows you to mock any function in your unit tests and verify your code for logical integrity.

The biggest benefit of CMock is that it allows us to add assertions for: function calling order, parameters passed to functions outside of our unit and insert return values for these functions. All of this together make CMock and irreplaceable tool for writing effective unit tests.

To test the entire system, I’ll also introduce you to Renode, a simulator that lets you run your final firmware and run user scenarios against it, verifying the integrity of the entire system. You’ll learn how to simulate your firmware through Renode and write scenarios in robot framework syntax.

Lastly, we will add code coverage checking to ensure that no source file is merged unless it has been fully tested. With our comprehensive testing infrastructure in place, you’ll have the confidence to say with assurance that your software has been verified to work according to set requirements.

Release Generation

The "Release Generation" section is the final part of this course on Zephyr RTOS CI/CD setup. In this section, we will add ability to generate final release of our firmware using the CI infrastructure that we have setup earlier.

First, we will add software BoM (Bill of Materials) generation to our project. This step is important because it allows us to have a list of all the files that were included in the binary. This list is useful for auditing purposes and helps us keep track of what went into the release and how well it has been tested.

Next, we will add the code to generate a final release archive. Having a final release archive will allow us to deploy the release to production and have a way of tracing each release to the components that went into it.

Reasons to do this training

This training aims to help you setup a comprehensive continuous delivery infrastructure using Zephyr RTOS as the platform on which we build firmware. While it is not strictly necessary to have a fully functional CI pipeline, it is absolutely essential to have it if you want to avoid collecting technical debt and running into maintenance problems later.

A properly setup pipeline will ensure that every tasks that is done remains done. We can achieve this by creating a pipeline that places requirements on developers to always complete each task in full before it can be merged. With this approach you minimize technical debt and make sure that your project always remains in perfect shape as the project evolves.

A few additional reasons why you would want to do this training include:

How to get this course

If you are already a member you should have access to all sections of this training.

If you are not a member then sign up below.

Click here to sign up