sewshyi

Geplanter Bearbeitungszeitraum bla bla --- AusgangssituationDas 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. --- ProjektzielZiel 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 --- Anlagenbla bla --- Präsentationsmittel Laptop, Beamer, Präsentation (Slides), ggf. Live-Demo der optimierten Pipeline-Ausführung, KI?