pantrag_fisi Projektantrag: Einführung eines Systems zur automatischen Image-Erstellung und -Verteilung im Bereich IoT und Gebäudeautomatisierung

[joeh-fisi]

Hallo zusammen,

ich habe am 14.09. meinen Abgabetermin für den Projektantrag und habe jetzt einen ersten Entwurf ausgearbeitet. Über konstruktive Kritik würde ich mich sehr freuen.

Als Hintergrundwissen:

Ich mache eine Umschulung zum Fisi in Berlin und befinde mich gerade im betrieblichen Praktikum bei einer kleinen Firma, wo ich der erste Praktikant überhaupt bin.  Von der  Bildungseinrichtung gibt es erschreckend wenig Unterstützung, ich warte momentan seit einer Woche auf eine Antwort bezüglich eines von mir vorgeschlagenen Projektthemas. Inzwischen hat sich aber auch ein anderes Thema ergeben, welches ich jetzt hier vorstelle.

Ich bin mir vor allem beim Thema Komplexität recht unsicher und hoffe auf eure Unterstützung.

 

1 Projektbezeichnung

Einführung eines Systems zur automatischen Image-Erstellung und -Verteilung im Bereich IoT und Gebäudeautomatisierung

1.1 Kurzform der Aufgabenstellung

Für die Firma xyz sollen verschiedene Lösungen zur automatischen Erzeugung und Verteilung von Betriebssystemimages für Embedded Linux Geräte in einer Testumgebung miteinander verglichen werden. Dies beinhaltet das Software-System, welches eine kontinuierliche Integration und Auslieferung (CI/CD) ermöglicht, als auch die benötigten Hardwareressourcen. Die Auswahl der geeigneten Gesamtlösung erfolgt dann mittels festgelegter Kriterien. Anschließend soll das neue System in einer Testumgebung eingeführt und und mit 3 ausgewählten Testgeräten getestet werden.

1.2 Projektziele

Das Ziel des Projektes ist es, ein Gesamtsystem zu evaluieren und einzuführen, welches ein automatisches Erstellen und Verteilen vom Betriebssystemimages ermöglicht. Durch die Standardisierung und Automatisierung sollen die Entwickler der Firma entlastet, unnötige Wartezeiten vermieden und mögliche Fehlerquellen ausgeschaltet werden. Dadurch kann wertvolle Entwicklerarbeitszeit sinnvoller genutzt und somit Kosten eingespart werden.

Für das Projekt wird ein Zeitrahmen von 3 Wochen angesetzt, wobei das spätest mögliche Projektende der 29.10.2021 ist.

2 Projektbeschreibung

2.1 Wie sieht die Ausgangssituation vor Projektbeginn aus?

Die Firma xyz entwickelt mittels agiler Methoden Betriebssysteme im Bereich IoT und Gebäudeautomatisierung. Die entwickelte Software läuft dabei auf Embedded Linux Geräten und muss auf eben diesen auch getestet werden. Dafür existiert bereits eine Testumgebung in den Räumen der xyz, mit einer repräsentativen Auswahl der verwendeten Geräte. Die Geräte sind dabei Teil eines separaten Netzwerkes.

Bevor die Entwickler ihre Änderungen auf den Testgeräten testen können, müssen sie momentan mehrere Schritte manuell ausführen bzw. anstoßen. Der jeweilige Entwickler baut auf seinem Notebook mittels Yocto das neue OS-Image, erstellt mit diesem Image ein neues Startmedium (z.B. SD-Karte), wechselt das Startmedium in dem Testgerät und führt einen Kaltstart aus. Erst anschließend kann er seine Testskripte starten und die Ergebnisse dokumentieren.

Dieses führt zu unproduktiven Wartezeiten und erhöht allgemein auch die Fehleranfälligkeit. Allein das Bauen des OS-Images auf dem Notebook des Entwicklers kann teilweise mehrere Stunden dauern. Zudem können die Teilschritte nicht i.d.R. nicht parallelisiert werden und es besteht keine reproduzierbare Build-Umgebung.

 

2.2 Was soll am Ende des Projektes erreicht sein?

Ziel des Projektes ist es, die vorherigen manuellen Schritte zu automatisieren. Änderungen im Git-Repository sollen einen Buildprozess auf einem leistungsfähigen Server auslösen. Die dabei erzeugten Images sollen dann ebenfalls automatisch auf die betroffenen Testgeräte ausgerollt werden. Auch der Kaltstart der Geräte (power cycle) und das Starten der Testskripte sollen automatisch erfolgen. Die Testergebnisse müssen auch automatisch dokumentiert werden.

Das neue System soll in einer Testumgebung implementiert werden und die Funktionalität mit 3 ausgewählten Testgeräten getestet werden.

 

2.3 Welche Einschränkungen müssen berücksichtigt werden?

- Auf den Servern wird Debian verwendet, da es das Standardsystem im Unternehmen ist.

- Ein firmeninterner Git-Repository-Server (Gitea) ist bereits vorhanden.

- Das bestehende Testframework muss weiter verwendet werden.

- Eine Liste der benötigten Pakete und Tool Chains zur Herstellung der Buildumgebung,  wird von den Entwicklern bereit gestellt. 
 

3 Projektphasen mit Zeitplanung in Std.

3.1 Planungsphase 3 Std.

3.1.1 Ist-Analyse 1 Std.

3.1.2 Soll-Konzept 2 Std.

 

3.2 Konzeptionsphase 9 Std.

3.2.1 Recherche Software-Lösungen 4 Std.

3.2.2 Recherche benötigter Hardwareressourcen 2 Std.

3.2.3 Evaluation (Kosten-Nutzen-Analyse) und Auswahl der Gesamtlösung 2 Std.

3.2.4 Zwischenpräsentation der Ergebnisse 1 Std.

 

3.3 Durchführungsphase 15 Std.

3.3.1 Herstellen der reproduzierbaren Buildumgebung (Server, Software, Bibliotheken) 5 Std.

3.3.2 Konfiguration des Software-Systems für die kontinuierliche Integration und Auslieferung 7 Std.

3.3.3 Aufbau Testumgebung mit 3 Testgeräten 1 Std.

3.3.4 Funktionalitätstest 2 Std

 

3.4 Abschluss des Projektes 8 Std.

3.4.1 Ist-Soll-Vergleich 2 Std.

3.4.2 Projektdokumentation 5 Std.

3.4.3 Abschlussgespräch und Präsentation 1 Std.

 

 

[charmanta]

Ich hab nur so ein bisschen Sorge dass Du zuviel Scripte schreibst, sonst halte ich das für zulassungsfähig

[joeh-fisi]

Das klingt ja schon mal super. Vielen Dank für das schnelle Antworten.

Ich habe mich während des Praktikums schon ein wenig mit ansible beschäftigt und werde dieses "geballte" Wissen vermutlich bei diesem Projekt einsetzen können.

[Griller]

Es ist schön, dass du mit ansible umgehen kannst, das sollte allerdings wirklich nicht Hauptaugenmerk sein, wenn du als Fisi geprüft wirst. Für einen Fisi wäre es sehr passend, ein CICD System zu evaluieren und zu installieren. Ggf. Kann man anschließend auch eine Testpipeline aufbauen, etc. Du solltest einfach nur aufpassen, dass der Skript-/Programmieranteil keine Überhand nimmt. Grundsätzlich finde ich das Projekt ganz schön, ist auf jeden Fall Mal was anderes.

[charmanta]

Ich schliesse mich an. Ansible geht zu sehr in den Bereich AE ... das dürfte so dann eher nicht durchgehen

[joeh-fisi]

Danke für das Feedback. Vielleicht überschätze ich mich da ja gnadenlos, aber ich schätze den Aufwand zum Erstellen der ansible-playbooks auf maximal 2h. Das ist natürlich auch davon abhängig welche "Hardwarelösung" ausgewählt wird. Falls es ein Cloudanbieter werden sollte, wie z.B. Hetzner oder Digitalocean, dann gibt es für diese sehr schöne APIs, mit deren Hilfe man Server erzeugen, umbauen und auch wieder löschen kann. Falls es ein eigener Root-server wird, dann geht es eher "nur" darum, Pakete zu installieren, Variablen zu definieren und Toolchains verfügbar zu machen.

Aber wie schon Anfangs erwähnt, ist es für mich schwer die Komplexität einzuschätzen. Ich hatte auch schon überlegt mich auf  die Auswahl des CI/CD-Systems zu konzentrieren und die Hardware als gegeben anzunehmen, z.B. eigener Rootserver. Oder alternativ das CI/CD-System als gegeben anzunehmen und mich auf die Auswahl der geeigneten "Hardware" zu konzentrieren und das Testsystem aufzubauen.