sewshyi

Geplanter Bearbeitungszeitraum
bla bla
---
Ausgangssituation
Das Ausbildungsunternehmen ist ein Softwareentwicklungsunternehmen mit rund 29 Mitarbeitern, das sich auf die Entwicklung von E-Commerce-Lösungen und webbasierten Anwendungen spezialisiert hat. Das Unternehmen gliedert sich in mehrere Entwicklungsteams sowie eine IT-Abteilung, die für den Betrieb und die Weiterentwicklung der internen Infrastruktur zuständig ist. Der Auszubildende ist in dieser IT-Abteilung eingesetzt, die Aufgaben aus den Bereichen Systemadministration und DevOps (Development Operations – die Verzahnung von Softwareentwicklung und IT-Betrieb) vereint. Die Entwicklungsteams verwalten ihre Softwareentwicklungsprozesse über eine selbst gehostete GitLab-Instanz. GitLab ist eine webbasierte Plattform zur Versionsverwaltung und Projektorganisation. Ein zentraler Bestandteil davon ist die CI/CD-Pipeline (Continuous Integration / Continuous Deployment – automatisiertes Bauen, Testen und Ausliefern von Software), die nach jedem Code-Push automatisch ausgeführt wird. Für die Ausführung dieser Pipelines betreibt die IT-Abteilung derzeit fünf sogenannte GitLab Runner – Prozesse, die auf dedizierten physischen Servern im unternehmenseigenen Serverraum laufen und die einzelnen Pipeline-Aufgabe (sog. Jobs) entgegennehmen und verarbeiten. Vier dieser Runner nutzen den Docker-Executor, bei dem jeder Job in einem isolierten Container (einer abgeschotteten Softwareumgebung) ausgeführt wird. Ein weiterer Runner arbeitet mit dem Shell-Executor, bei dem Jobs direkt auf dem Host-System ausgeführt werden. Die Verwaltung der gesamten Infrastruktur – einschließlich der Runner-Konfiguration – erfolgt über IaC (Infrastructure as Code), konkret über Ansible-Playbooks (automatisierte Konfigurationsskripte).. Im Zuge des Unternehmenswachstums und der zunehmenden Anzahl paralleler Entwicklungsprojekte kommt es vermehrt zu Engpässen in der Pipeline-Ausführung: Jobs werden in Warteschlangen eingereiht und verzögern den Entwicklungsworkflow der Teams. Auswertungen des bestehenden Monitoring-Systems – bestehend aus Prometheus (einem System zur Metrikerfassung) und Grafana (einem Werkzeug zur grafischen Darstellung von Metriken) – zeigen, dass die durchschnittliche Wartezeit eines Jobs in der Queue bei ca. 13–15 Minuten liegt. Die durchschnittliche Ausführungsdauer eines Jobs beträgt dabei lediglich ca. 3 Minuten – Jobs warten also im Schnitt etwa fünfmal länger auf ihren Start als die eigentliche Ausführung dauert. In der zuletzt betrachteten Woche wurden insgesamt 2.906 Pipeline-Jobs ausgeführt. Dies führt zu verlängerten Feedbackzeiten für Entwickler sowie einem messbaren Rückgang der Entwicklungsgeschwindigkeit. Es ist bisher ungeklärt, ob die Engpässe auf eine unzureichende Anzahl von Runnern, eine suboptimale Konfiguration der bestehenden Infrastruktur oder strukturelle Ursachen (z. B. ineffiziente Pipelines) zurückzuführen sind. Eine fundierte Analyse der Ist-Situation sowie eine Bewertung möglicher Lösungsansätze sind daher erforderlich.
---
Projektziel
Ziel des Projekts ist die systematische Analyse der bestehenden GitLab-Runner-Infrastruktur sowie die Identifikation und Behebung der Pipeline-Engpässe. Dabei wird zunächst geprüft, ob Optimierungspotenzial in der bestehenden Konfiguration besteht, bevor eine Erweiterung der Infrastruktur in Betracht gezogen wird. Verschiedene Lösungsansätze – darunter physische Erweiterungen, virtualisierungsbasierte Konzepte sowie containerbasierte und autoskalierbare Architekturen – werden anhand eines strukturierten Kriterienkatalogs evaluiert. Die Bewertung berücksichtigt technische Anforderungen (Skalierbarkeit, Build-Isolation, Netzwerkintegration), Sicherheitsaspekte (Host-Härtung, Secret Management) sowie wirtschaftliche Faktoren (Beschaffungs- und Betriebskosten,TCO-Vergleich).
Erfolgskriterien:
- Reduktion der durchschnittlichen Pipeline-Wartezeit
- Steigerung der parallelen Pipeline-Kapazität
- Einhaltung der Sicherheitsanforderungen gemäß Schutzbedarfsanalyse
- Wirtschaftliche Vertretbarkeit der gewählten Lösung
---
Zeitplanung (gesamt 40 Stunden)
1. Analysephase (10 h)
- Erhebung der Ist-Situation (Metriken, Logs, Konfiguration): 3 h
- Identifikation der Engpass-Ursachen (Rootcause-Analyse): 3 h
- Anforderungserhebung mit Stakeholdern: 2 h
- Recherche möglicher Lösungsansätze: 2 h
2. Planungsphase (10 h)
- Erstellung eines Kriterienkatalogs: 2 h
- Evaluation der Lösungsalternativen: 3 h
- Wirtschaftlichkeitsbetrachtung (TCO-Analyse): 2 h
- Schutzbedarfsanalyse & Sicherheitskonzept: 2 h
- Entscheidungsdokumentation & Detailplanung: 1 h
3. Durchführungsphase (13 h)
- Vorbereitung der Infrastruktur: 3 h
- Installation & Konfiguration des/der neuen Runner(s): 3 h
- Netzwerkintegration (VLAN, Firewall-Regeln): 3 h
- Integration in GitLab & Anbindung an bestehende Infrastruktur: 2 h
- Funktionstests & Lasttest: 2 h
4. Abschlussphase (7 h)
- Soll-Ist-Vergleich & Qualitätssicherung: 1 h
- Projektdokumentation: 6 h
---
Anlagen
bla bla
---
Präsentationsmittel
Laptop, Beamer, Präsentation (Slides), ggf. Live-Demo der optimierten Pipeline-Ausführung, KI?

Ich würde hier gerne noch hinzufügen, dass die neuen Fachrichtungen aus meiner Erfahrung längst nicht bei allen Firmen angekommen sind.
In der Vergangenheit wäre das aus meiner Sicht sowohl für FiSi, als auch für FiAE interessant gewesen (als Abschlussprojekt für FiAE mit anderem Fokus, klar). Das kommt ganz darauf an, wie eine Firma DevOps lebt. Ich habe alle Formen in der Praxis bereits gesehen (die Bewertung lasse ich jetzt mal außen vor, das wäre was für einen eigenen Thread):
zentrales Platform- oder Operations-Team kümmert sich um die Infrastruktur, Runner sind self-hosted (dann eher FiSi)
DevOps (oder Platform, you name it) -Engineers sind Teil der Dev-Teams (dann meist FiAE, aber ich kenne auch FiSi, die diesen Weg gegangen sind - mich eingeschlossen), Runner sind eher als managed Service eingekauft (aber nicht immer oder ausschließlich, irgendeinen OnPrem Runner für legacy Zeugs im Serverschrank gibt es immer)
Es gibt überhaupt kein Platform/Ops-Team oder DevOps-Engineers, mit der Begründung, dass das eine Philosophie und kein Jobtitel ist (dann machen die FiAE das in ihren Teams mit) --> you build it, you run it
Das CI/CD-Thema (inkl. Runner-Infrastruktur) lernen bei uns sowohl FiSi als auch FiAE, auch wenn es in den Development-Teams oft eher als managed Service genutzt wird.
Und um noch auf das Thema zurückzukommen:
Klasse Projekt aus meiner Sicht! Praxisnah und relevant. @sewshyi Falls du da später noch Fragen hast, melde dich gerne. Ich hoffe, das wird genehmigt.

Boah das ist schwierg. Auch wenn formal alles drin ist seh ich das als FIDV Thema und würde das ablehnen. Dazu kommt dass das nicht jeder Prüfer fachlich beurteilen kann ( vermute ich )

was sagen denn zb @skylake @ickevondepinguin dazu?

Bin da geteilter Meinung.
Ich finde, hier steckt durchaus recht viel FiSi drin, in diesem Satz. Ich stimme aber @charmanta zu: Vom Gesamtumfang und dem IST-/SOLL-Bild sehe ich insgesamt auch eher den FIDV. Frage die ich mir aber hier immer stelle ist: Wer hat das denn vor dem FIDV bearbeitet? Ggf. bekommst du es ja hin, dass es mehr nach FiSi als nach FiDV klingt. Wobei ich sagen muss, dass das IST eben sehr den FiDV entspricht. Das SOLL und dann die Tätigkeiten in der Zeitplanung eher dem FiSi entsprechen können.
Bei uns würde das Thema auch bei einem FiSi "durch kommen" und wäre eines der spannenderen Projekte. Kann da aber nur für meinen PA sprechen natürlich.