-
- Übersicht
- Die DH-Welt
- Case Studies
- News
- FAQ
- Qualität
- Über uns
- Über DH electronics
- TOP 100 Innovator
- Karriere
- Entwicklerwelt
- Support
- Events
down
Komponenten und Tools
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.
Woher der Quellcode für einen Build gezogen wird. (Möglicherweise eines oder mehrere).
Plattform, welche die benötigten Werkzeuge zur Verwaltung des gesamten Softwareentwicklungslebenszyklus bietet
Containerisiertes System, auf welchem die CI/CD Pipeline ausgeführt wird
Dazu gehören Unit-, Integrations-, System- und Regressionstests.
Analyse der Software mit Prüfung auf Einhaltung von Codierungsstandards, Analyse von Metriken, Sprachkorrektheit usw.
Verwendung virtueller Hardware zum Testen und Überprüfen der Korrektheit der Software.
Eine Methode zur Bereitstellung neuer Firmware für das Produkt, nachdem sie alle automatisierten Tests und manuellen Gates erfolgreich durchlaufen hat.
Ein Mechanismus zur Überwachung des Fortschritts und zur Meldung des Softwarestatus sowie von Problemen, die möglicherweise untersucht werden müssen.
Analyse zur Ermittlung von Sicherheitslücken und zur Gewährleistung des Schutzes des Systems.
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.
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.
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.
