DH electronics GmbH
Zu Deutsch wechseln
scroll Scroll Down down

Processes and tools at DH electronics

Components and tools

Processes and tools at DH electronics

Test and build automation

A CI/CD pipeline is an automated process and forms the basis of test and build automation. It is made up of individual stages and is used to make the creation, testing and deployment of software components more efficient, reliable and faster. This is used in modern software development and makes it easier for you to deliver quick, small improvements to the software, i.e. to continuously integrate code changes and automatically test and deploy them.

Components of a CI/CD pipeline

  • Git repositories with source code

Where the source code for a build is taken from. (Possibly one or more).

  • Gitlab

Platform that provides the tools needed to manage the entire software development lifecycle

  • Build system

Containerized system on which the CI/CD pipeline is executed

  • Automated tests

This includes unit, integration, system and regression tests.

  • Static code analysis

Analysis of the software with checks for compliance with coding standards, analysis of metrics, language correctness, etc.

  • Hardware emulation/simulation

Use of virtual hardware to test and verify the correctness of the software.

  • Deployment mechanism

A method of deploying new firmware to the product after it has successfully passed all automated tests and manual gates.

  • Monitoring and reporting

A mechanism for monitoring progress and reporting software status and issues that may need to be investigated.

  • Safety analysis

Analysis to identify security vulnerabilities and ensure the system is protected. (Security could also fall under static analysis, but I thought it was worth listing separately as it can easily be overlooked).

CI/CD structure at DH

The CI/CD structure at DH electronics GmbH is implemented with the GitLab tool. GitLab is used to store customer-specific source code, maintain, configure and execute software builds and trigger the test environment.

Yocto layer structure

Hier kommt ihr zum Yocto Layer Aufbau

Build strategy

By building and testing the customized project with the latest versions of the layers, these updates can be applied without manual effort. If the build and tests are successful, the latest layers can be used directly for further custom hardware development. If the process fails, DH electronics receives timely feedback on which part of the test failed and where additional work is needed when a new custom BSP release is due.

Kernel build strategy

In the past, the kernel sources for customer-specific hardware were provided as a customer-specific branch of a repository provided by DH electronics. Therefore, updating to the latest kernel patch level required manual effort. With the integration of customer devices into the CI/CD structure, the kernel repository is switched to the customer-specific Yocto patches. The reason for this is that kernel updates can be applied automatically with this procedure.

Background: For current Yocto sources, it is possible to provide customer-specific patches for the mainline kernel instead of a complete software repository. By updating the Yocto layers, the kernel version used is also updated and the patches provided are applied to this version. As long as the build does not fail during the patch process, no manual work is required. If the build fails, this is early feedback on what needs to be checked when an update is due.

DH Testrack

  • Customer hardware is integrated into the DH test rack
  • GitLab based CI/CD pipeline
  • Releases are delivered via GitLab
  • The releases are tested on customer hardware with standard tools and test scripts
  • If errors occur in the test rack during testing, they are corrected to avoid later problems in the field
+