Welcome to this comprehensive course on Zephyr RTOS CI/CD setup!
- If you are struggling with implementing a continuous delivery process for your embedded firmware..
- If you want to improve the reliability of your CI infrastructure and have confidence in the parts of your software that have been verified to work according to set requirements..
- If you are looking to manage your team more effectively with a proper CI/CD infrastructure in place..
Then this course is for you!
This course not only helps you implement a continuous delivery process for your firmware but also serves as a comprehensive "Zephyr RTOS Getting Started Guide".
What sets this guide apart from the existing ones and the ones before it is that it is aimed at helping you set up your custom firmware application development in a standalone repository using Zephyr RTOS as your main platform but removing the need to be working directly in the Zephyr RTOS git repository.
While existing guides such as the Zephyr RTOS getting started guide focuses on getting started working ON Zephyr, this guide focuses on what you need to do in order to start working WITH Zephyr and developing your own firmware using it.
The course is divided into six parts, each covering a crucial aspect of the CI/CD setup process:
The training is divided into 6 parts:
- Overview - a quick overview of the course - similar to this page.
- Setting up repository - shows you how to configure the repository correctly from scratch, adding the first robot framework scripts, required files such as CMake files, Kconfig files, CODEOWNERS, gitignore, and more. It also covers adding a pre-commit hook that runs checks on changed files before each commit and a repository init script that sets up local repository and system after a checkout.
- Setting up GitLab CI - covers configuring a CI pipeline through .gitlab-ci.yml, creating a proper task template, building docker images, adding a merge request template, configuring the repository for trunk-based development, adding check to ensure that merge request title contains clickable reference to ticket being solved, and adding Zephyr compliance checking scripts.
- Building Docker Images in CI - this section covers how you can create a fully version controlled and reproducible build environment for gitlab using gitlab CI itself to build the CI docker images on top of which you can then build your firmware. In this section we cover how to set up your gitlab runners and CI pipelines for creating a docker image and publishing it to docker hub.
- Directory Structure - provides a comprehensive directory structure that can accommodate for everything you may add to your project later, including an example application, a custom board, a cmake library directory, an example device driver, a documentation folder, a global include directory, an example library, and example samples.
- Documentation Generation - teaches you how to adopt Zephyr documentation generator to work in an external repository, add robot framework scripts for verifying chapter structure, link the docs together to generate a single PDF or HTML output, and add the doc build process to CI, making everything pass all CI checks that we have setup earlier.
- Test Infrastructure - focuses on testing and covers adding unity, CMock, renode support, and code coverage checking to verify logical integrity and ensure that we don’t allow any source file to be merged unless it has been fully tested.
- Release Generation - here we take everything that we have added so far and build a final release, including software BoM, documentation and firmware images all packaged up into the final firmware release archive.
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.
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.
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.
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.
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:
- You are tired of unreliable CI infrastructure
- You want to be able to say with confidence what parts of your software have been verified to work according to clearly set requirements.
- You want to become better at managing your team (with proper infrastructure in place, team can easily apply the scrum workflow. This is very hard to do effectively without a build infrastructure detailed in this training)
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.