Warum CI/CD im Embedded-Bereich anders ist
In der klassischen Webentwicklung ist CI/CD längst Standard. Im Embedded-Bereich sieht die Realität oft anders aus: Builds laufen auf dem Rechner des Entwicklers, Tests werden manuell auf der Hardware durchgeführt, und Firmware-Updates werden per USB-Stick übertragen. Das funktioniert -- bis das Team wächst, die Produktvarianten zunehmen und die Release-Zyklen kürzer werden sollen.
Jenkins kann auch für Embedded-Projekte eine leistungsfähige CI/CD-Plattform sein. Aber die Herausforderungen unterscheiden sich erheblich von einem typischen Java- oder Node.js-Projekt. Cross-Compilation, Hardware-Abhängigkeiten und lange Build-Zeiten erfordern durchdachte Pipeline-Architekturen.
Build: Cross-Compilation in Jenkins
Embedded-Software wird selten auf derselben Architektur gebaut, auf der sie läuft. Ein ARM-Cortex-M Mikrocontroller braucht eine ARM-Toolchain, ein ESP32 die Espressif-Toolchain. Jenkins muss diese Toolchains bereitstellen, idealerweise als Docker-Container:
pipeline {
agent {
docker {
image 'arm-gcc-toolchain:12.2'
args '-v /opt/licenses:/opt/licenses:ro'
}
}
stages {
stage('Build') {
steps {
sh 'cmake -DCMAKE_TOOLCHAIN_FILE=arm-cortex-m4.cmake -B build'
sh 'cmake --build build --parallel'
}
}
stage('Unit Tests') {
steps {
sh 'cmake --build build --target test'
}
}
stage('Static Analysis') {
steps {
sh 'cppcheck --enable=all --xml src/ 2> cppcheck-report.xml'
}
}
}
}
Docker-basierte Build-Agents haben den großen Vorteil, dass die Toolchain-Version fixiert und reproduzierbar ist. Kein "bei mir baut es aber" mehr, weil jeder Build in derselben Umgebung läuft.
Umgang mit proprietären Toolchains
Viele Embedded-Toolchains -- etwa von IAR, Keil oder Texas Instruments -- sind proprietär und erfordern Lizenzen. Das bedeutet:
- Lizenzdateien müssen dem Build-Agent zugänglich sein (Volume Mount oder Netzwerklizenz)
- Die Anzahl paralleler Builds ist durch Lizenzen begrenzt
- Docker-Images mit proprietärer Software können nicht öffentlich verteilt werden
Jenkins' lock-Step hilft, die Anzahl gleichzeitiger Builds auf die verfügbaren Lizenzen zu begrenzen.
Test: Vom Unit-Test bis Hardware-in-the-Loop
Unit-Tests auf dem Host
Unit-Tests für Embedded-Code sollten, wo möglich, auf dem Host-System laufen. Frameworks wie Unity, CppUTest oder Google Test ermöglichen schnelle Feedback-Zyklen ohne Hardware. Voraussetzung ist, dass der Code sauber von der Hardware-Abstraktionsschicht getrennt ist -- ein Designprinzip, das sich allein schon wegen der Testbarkeit lohnt.
Hardware-in-the-Loop (HiL)
Für Tests, die echte Hardware erfordern, brauchen Sie dedizierte Test-Stationen. Ein Jenkins-Agent mit physischem Zugang zur Zielhardware flasht die Firmware, führt Tests aus und sammelt Ergebnisse ein. Das erfordert Planung:
- Teststation-Management: Hardware-Ressourcen sind begrenzt -- Jenkins muss Zugriff koordinieren
- Firmware-Flash: Automatisiert über J-Link, OpenOCD oder herstellerspezifische Tools
- Ergebnis-Erfassung: Serielle Konsole, Messgeräte-Anbindung oder GPIO-basierte Signale
Die grösste Herausforderung ist die Zuverlässigkeit. Hardware-Tests können durch lose Kabel, defekte Boards oder Timing-Probleme fehlschlagen. Robuste Retry-Mechanismen und klare Eskalationspfade sind Pflicht.
Deploy: Firmware-Verteilung
Das Deployment von Firmware unterscheidet sich grundlegend von einem Webservice-Deployment. Typische Szenarien:
- OTA-Updates: Die Pipeline stellt das Firmware-Image auf einem Update-Server bereit, Geräte im Feld laden es herunter
- Produktions-Programmierung: Firmware-Images werden an die Fertigungslinie geliefert, wo sie auf neue Geräte geflasht werden
- Test-Deployment: Automatisches Flashen auf Testgeräte im Labor
In allen Fällen ist Versionierung entscheidend. Jedes Firmware-Image muss eindeutig einem Git-Commit zugeordnet werden können. Jenkins Artefakt-Management in Kombination mit einem Binary-Repository wie Artifactory oder Nexus bietet die nötige Nachvollziehbarkeit.
Fazit
CI/CD für Embedded Systeme mit Jenkins ist machbar und lohnt sich -- aber es erfordert ein anderes Toolset und andere Denkweisen als in der Web-Entwicklung. Der grösste Hebel liegt in der Automatisierung von Build und Unit-Tests. Hardware-in-the-Loop-Tests sind der nächste Schritt, der die meiste Infrastruktur erfordert, aber auch den grössten Qualitätsgewinn bringt.
In unserem Jenkins Essential Training vermitteln wir die Grundlagen, auf denen Sie auch Embedded-Pipelines aufbauen können. Für Teams, die bereits mit Jenkins arbeiten, bietet das Jenkins Pipeline Experten Training vertiefte Einblicke in fortgeschrittene Pipeline-Architekturen.
