CICD - automatisierter Build & Test (SW,HW)

1

Hallo alle miteinander,

die Pflege meines Affenbox-Forks stellt mich immer wieder vor ein paar zeitlichen Herausforderungen.
Das Testen meiner Änderungen und Pull Request auf Git Hub ist oft zeitaufwändiger als das Programmieren. Grund sind die vielen Varianten und Ergänzungen die man Konfigurieren könnte.

Parallel möchte ich mich beruflich auch in Softwareprojekten versuchen.

Hier passiert nun die Verbindung.

Genau diese Themen sind bei uns gerade sehr heiß. Stichworte wie DevOps, CI/CD, Docker, Kubernetes sind zwar nichts Neues im Allgemeinen, allerdings wird in unserem Bereich Software immer wichtiger als Hardware und diese Themen sind wichtig wenn es um die Qualität der Softwareentwicklung und des Endproduktes geht.

Ja und was hat das jetzt mit TonUINO und meinem Forks zu tun?

Ich habe einen selbst gehosteten Jenkins Server aufgesetzt und mit einem Build- und Testknoten versehen und das ganze in meinem Repository Integriert.
Wenn ihr oder ich eine Änderung in Form eines Pull Requests oder eines Push hochladen, bekommt mein Server eine Meldung und baut automatisch die Software in den gängigen Konfigurationen(3/5 Buttons, Analoge Taster, IR,…) und für die beiden Plattformen (AiO, Arduino Nano).
Eine Rückmeldung bekommt ihr dann auf GitHub, sobald der Build abgeschlossen wurde.
Ein kleiner grüner Haken markiert das alles i.O. ist:

Unbenannt
Unbenannt919×570 48.2 KB

In der Übersicht der Pull Requests:
Unbenannt

Im Pull Request ist es dann auch nochmal dargestellt:

Unbenannt
Unbenannt925×247 19.5 KB

Was steckt dahinter?
Die verwendete Software ist Jenkins und PlatformIO CLI

Als Hardware verwende ich Raspberry Pis (2x Pi 4 & 1x Pi Zero 2), die ich in einem selbst gedruckten 6" Rack unterbringe:

20220411_014549
20220411_0145493024×4032 1.33 MB

20220411_014557
20220411_0145573024×4032 1.37 MB

Der Aufbau steckt noch etwas in der Entwicklungsphase. Es fehlt noch ein Test-TonUINO, der autmoatisiert per Script bedient werden kann.

Das ist aber erst der Anfang!
Ich plane noch folgende Ergänzungen:

  • Einsicht der Testprotokolle für jeden
  • Aufbau eines kompletten HW Test mit einem angeschlossenen TonUINO am Rack
  • Test der SW ohne HW über eine AVR Simulation (SimulAVR) auf einem Pi
  • Auslagern der Builds und Tests in Docker Container
  • Skalierung der Container über Kubernetes um alle Varianten parallel testen zu können, das wird aber wahrscheinlich potentere HW voraussetzen
8 „Gefällt mir“
2

Ich habe keine Ahnung was du da schreibst, aber ein Herzchen ist es mir wert

4 „Gefällt mir“
3

:sweat_smile:

Zugegeben, das Thema ist für den TonUINO extrem abgehoben und 98% aller User hier werden wie du nur Bruchteile dessen schon Mal gehört oder gesehen haben. Ich habe davon selbst erst vor ein paar Wochen erfahren und mich gefragt: „Warum habe ich das noch nie in einem Projekt gesehen oder im Zusammenhang davon gehört?“

Aber ich finde das Thema hoch spannend. Völlig automatisiert Software zu testen und nach ein paar Minuten ein Ergebnis zu haben, das mir sagt: „alles Gut, deine Änderungen funktionieren“
oder auch direkt ein Pull Request bewerten zu können, damit ich nur noch Kleinigkeiten testen muss.
So vermeide ich einfach große und kleine Fehler, wie sie schon oft passiert sind.
Vor allem bekommt jeder dieses Ergebnis auf GitHub zu sehen und kann die Qualität der Software daraus ableiten.

Ich habe das gepostet um:
a) um den 98% zu zeigen in welche Richtung man sich mit einem Softwareprojekt bewegen kann und was es da draußen alles gibt
b) um den 2%, die was damit anfangen können, zu zeigen: hier geht was
c) um anzukündigen was der Affenbox Fork gerade macht und wie er sich in Zukunft verbessern wird

1 „Gefällt mir“
4

Das ist jetzt schon sehr professionell und übersteigt auch meine mehr hobbymäßigen Programmierkünste. Trotzdem finde ich das gut, zumal Du ja auch berufsmäßig mit sowas zu tun hast. Warum soll man nicht auch im privaten Umfeld von seinen berufsmäßigen Fähigkeiten profitieren.

1 „Gefällt mir“
5

Einen Schritt, bei dem ich mir aber noch nicht sicher bin ob ich ihn gehen, wäre diesen „Dienst“ für alle Versionen hier zu Verfügung zu stellen. Im Grunde sind die TonUINOs ja immer gleich.
Das Bedarf nur einer Datei im Repository und zwei Clicks in Jenkins, dann wird zumindest mal ein Build durchgeführt.
Damit das aber machbar ist muss ich eine Benutzerverwaltung auf die Beine stellen.

Edit: ich versuche im übrigen genau das Gegenteil. Beruflich habe ich noch nichts damit zu tun, aber das Thema kommt gerade auf und ich versuche mich darin einzuarbeiten.

6

Beeindruckend! Ich beschäftige mich mit automatisierten Softwaretests im Bezug auf Anwendungssoftware und finde das schon ausreichend komplex. Da jetzt noch ne Hardwareebene draufzupacken macht das Ganze ja nicht gerade einfacher. Bin mir ziemlich sicher dass das Thema zukünftig immer wichtiger wird. Gerade wenn man längerfristig plant spart man sich ja einiges an manuellem Testaufwand.

7

Die Hardwareebene ist das in dem ich mich aktuell beruflich bewege, deshalb fällt mir das leichter.

Auf der Softwareebene sprechen wir hier ja von einem Arduino Projekt. Das ist ja im Vergleich zu richtiger Software nicht soo komplex.

Und am Ende ist der Hardwaretest auch der Softwaretest in diesem Fall.

8

Na wenn das 2 Fliegen mit einer Klappe erschlägt ist das natürlich umso besser!

Spaßig wirds vermutlich erst wenn sämtliche DFPlayer Varianten abgebildet werden sollen :see_no_evil:

9

So schlimm stelle ich mir das mit den unterschiedlichen Playern gar nicht vor. Es gibt ja mittlerweile für fast jeden verfügbaren Player Lösungen um die Probleme zu lösen oder zumindest zu verringern.

10

Eine 100% Abdeckung wird nicht möglich sein.
Der Testaufbau lässt sich aber auch einfach duplizieren mit verschiedenen Komponenten.

Wie weit ich das treibe weiß ichnoch nicht

11

Coole Idee, das hier zu integrieren! Möglicherweise kannst du den reinen Compile-Test auch ohne eigenen Jenkins machen und komplett auf existierende Services zugreifen. Dann wäre das Setup auch leichter für andere Forka umsetzbar.

Ich habe mich damit allerdings nie eingehend beschäftigt und auch gerade keine Zeit. Daher nur ein paar Hinweise:

  • Man kann mit github.io Workflows definieren und automatisiert ausführen lassen (zB einmal die Nacht)
  • Es scheint in den github workflows auch platformio cli zu geben
  • Man könnte sich also evtl einen Workflow bauen der regelmäßig mit Hilfe von platformio für alle Varianten prüft ob der Code kompiliert
  • Ich habe keine Erfahrung ob sich das mit den Verfikationen der github pull requests verheiraten lässt, gehe aber davon aus, da die Workflows ja auch von github kommen
12

Hi, Danke für deinen Beitrag.

Ich weiß das es auch über gitHub möglich ist.
Es gibt noch viele andere Dienste.

Platformio bietet auch einen remote Service über den man ferngesteuert z.B. einen eignene Build oder Testknoten ansteuern könnte. Pio remote.

Erstmal nur an einen Build zu kommen ist relativ simpel.

Ich will das aber noch um ein paar Schritte weiter treiben, zwecks Einarbeitung. Daher ist es für mich aktuell sinnvoller das selbst zu hosten. Ich will die ganze Kette besser verfolgen können ohne das es in einer Cloud verschwindet.

13

kurzes Update:

Unbenannt

Der Test gibt die ersten Zeilen der seriellen Übertragung aus.
Die Ausgabe muss noch etwas bereinigt werden damit man sie auswerten kann.

1 „Gefällt mir“
14

20220503_003914
20220503_0039144032×3024 1.72 MB

Der Testaufbau steht.
Relais ersetzen die Schalter
und ein Servo führt einen RFID Tag vor den Reader.
Damit sind die Grundfunktionen automatisiert.

4 „Gefällt mir“
15

Du wirst mindestens zwei brauchen.

Modifikationskarten müssten vorher beschrieben werden.
Mit deinen Spielen brauchst du noch mehr…
Ich stelle mir gerade einen Trommelrevolver oder ein Fließband…
Der Reader wird dann per servo ran bewegt.

16

Ich dachte eher an einen zweiten Reader am Pi, der dann den Tag immer neu beschreibt. Das ist aber nur sekundär (wenn überhaupt nötig). In dem Test ist nur relevant ob der Tag erkannt wird und ob die Stopp wenn Karte weg Funktion, sowie der Speicher auf dem Tag funktionieren. Das ist alles mit einem machbar.

All Modis teste ich wahrscheinlich über die Shortcuts. Shortcuts kann ich jederzeit über das Adminmenü neu generieren und ändern.

Ich denke auch noch darüber nach einen Bypass in der SW zu generieren, der mir das weniger aufwendig zur Verfügung stellt. 100%ige Realitätsnähe ist nicht nötig um 100% der Funktionen abzutesten.

17

Seinen 3er Golf tiefer zu legen ist auch nicht notwendig, wird aber von bestimmten Gesellschaftsgruppen als cool empfunden.

2 „Gefällt mir“
18

Ich will es nur klein und funktional halten. Ich mag mich nicht mit mechanischen Problemen aufhalten. Dieser Servo ist schon so ne „Notlösung“, da es wahrscheinlich noch Aufwändiger wäre den NFC Tag über einen zweiten Reader zu emulieren.