DH electronics GmbH
scroll Scroll Down down

Prozesse und Tools bei DH electronics

Komponenten und Tools

Prozesse und Tools bei DH electronics

Test und Build Automation

Eine CI/CD-Pipeline ist ein automatisierter Prozess und stellt die Grundlage der Test und Build Automation dar. Dieser setzt sich aus einzelnen Stufen zusammen und dient dazu, das Erstellen, das Testen und die Bereitstellung von Softwarekomponenten effizienter, zuverlässiger und schneller zu machen. Dies wird in der modernen Softwareentwicklung genutzt und erleichtert es dir schnelle, kleine Verbesserungen der Software zu liefern, d.h. Codeänderungen kontinuierlich zu integrieren und automatisiert zu testen und bereitzustellen.

Komponenten einer CI/CD-Pipeline
  • Git-Repositorien mit dem Quellcode

Woher der Quellcode für einen Build gezogen wird. (Möglicherweise eines oder mehrere).

  • Gitlab

Plattform, welche die benötigten Werkzeuge zur Verwaltung des gesamten Softwareentwicklungslebenszyklus bietet

  • Build System

Containerisiertes System, auf welchem die CI/CD Pipeline ausgeführt wird

  • Automatisierte Tests

Dazu gehören Unit-, Integrations-, System- und Regressionstests.

  • Statische Code Analyse

Analyse der Software mit Prüfung auf Einhaltung von Codierungsstandards, Analyse von Metriken, Sprachkorrektheit usw.

  • Hardware Emulation/Simulation

Verwendung virtueller Hardware zum Testen und Überprüfen der Korrektheit der Software.

  • Bereitstellungsmechanismus

Eine Methode zur Bereitstellung neuer Firmware für das Produkt, nachdem sie alle automatisierten Tests und manuellen Gates erfolgreich durchlaufen hat.

  • Überwachung und Berichterstattung

Ein Mechanismus zur Überwachung des Fortschritts und zur Meldung des Softwarestatus sowie von Problemen, die möglicherweise untersucht werden müssen.

  • Sicherheitsanalyse

Analyse zur Ermittlung von Sicherheitslücken und zur Gewährleistung des Schutzes des Systems.

CI/CD-Struktur bei DH

Die CI/CD-Struktur bei DH electronics GmbH wird mit dem Tool GitLab realisiert. GitLab wird eingesetzt, um kundenspezifischen Quellcode zu speichern, Software-Builds zu pflegen, zu konfigurieren und auszuführen sowie die Testumgebung zu triggern.

Build Strategie

Indem das angepasste Projekt mit den neuesten Versionen der Schichten gebaut und getestet wird, können diese Aktualisierungen ohne manuellen Aufwand angewendet werden. Wenn der Build und die Tests erfolgreich sind, können die aktuellen Schichten direkt für die weitere kundenspezifische Hardwareentwicklung verwendet werden. Schlägt der Prozess fehl, erhält DH electronics zeitnahes Feedback, welcher Teil des Tests fehlgeschlagen ist und wo zusätzliche Arbeit nötig ist, wenn ein neues kundenspezifisches BSP Release ansteht.

Kernel Build Strategie

In der Vergangenheit wurden die Kernel Quellen für kundenspezifische Hardware als kundenspezifischer Zweig eines von DH electronics bereitgestellten Repositoriums bereitgestellt. Daher erforderte die Aktualisierung auf den neuesten Kernel Patch Level manuellen Aufwand. Mit der Integration der Kundengeräte in die CI/CD-Struktur wird das Kernel-Repository auf die kundenspezifischen Yocto Patches umgestellt. Der Grund dafür ist, dass mit dieser Vorgehensweise Kernel Updates automatisch eingespielt werden können.

Hintergrund: Für aktuelle Yocto Quellen ist es möglich, anstelle eines vollständigen Software Repositorys kundenspezifische Patches für den Mainline Kernel bereitzustellen. Durch die Aktualisierung der Yocto Schichten wird auch die verwendete Kernel-Version aktualisiert und die bereitgestellten Patches werden auf diese Version angewendet. Solange der Build während des Patch Prozesses nicht fehlschlägt, ist keine manuelle Arbeit erforderlich. Wenn der Build fehlschlägt, ist das eine frühe Rückmeldung, was bei einem fälligen Update überprüft werden muss.

DH Testrack

  • Die Kundenhardware wird ins DH Testrack integriert
  • GitLab basierte CI/CD-Pipeline
  • Releases werden über GitLab ausgeliefert
  • Die Releases werden auf Kundenhardware mit Standardwerkzeugen und Testskripten getestet
  • Wenn beim Test Fehler im Testrack auftreten, werden diese behoben um spätere Probleme im Feld zu vermeiden
+