Die Infrastrukturlücke, die die meisten Entwicklungsteams haben
In Entwicklungsteams ohne dedizierten DevOps-Ingenieur zeigt sich immer wieder dasselbe Muster: Anwendungen werden gut entwickelt, aber schlecht bereitgestellt. Der Code ist sauber, getestet und geprüft. Die Docker-Einrichtung ist notdürftig aus einem Tutorial übernommen, das für einen anderen Stack geschrieben wurde. Die CI/CD-Pipeline existiert entweder gar nicht, läuft unzuverlässig oder ist seit zwei Wochen defekt, und niemand hatte Zeit, sie zu reparieren. Die Infrastruktur wird manuell bereitgestellt, ist undokumentiert und würde bei einem Ausfall der Produktionsumgebung Tage benötigen, um sie neu zu erstellen.
Jede Bereitstellung unter diesen Bedingungen birgt Risiken. Eine fehlgeschlagene Bereitstellung bei hohem Traffic verursacht Ausfallzeiten. Eine fehlerhafte Sicherheitskonfiguration in der Infrastruktur macht die Anwendung anfällig für Sicherheitslücken, die eine korrekt konfigurierte Pipeline vor der Bereitstellung erkennen würde. Fehlt ein Health Check, empfängt ein fehlerhafter Container weiterhin Traffic. Nichts davon sind schwer zu lösende Probleme - sie erfordern jedoch DevOps-Wissen, über das das Team nicht verfügt, und Zeit, die das Team nicht hat, um es sich anzueignen.
Rupert - der DevOps agent von KissMySkills - schließt diese Lücke systematisch. Er stellt gezielte Fragen zum Tech-Stack, Cloud-Anbieter, den Bereitstellungsanforderungen und der bestehenden Einrichtung und erstellt anschließend vollständige, produktionsreife Konfigurationsdateien - keine Vorlagen zur Anpassung, sondern Dateien, die bereit sind, in das Repository committed, getestet und bereitgestellt zu werden.
Rupert erstellt deine Dockerfiles, CI/CD-Pipelines und Terraform-Module - produktionsbereit, mit Sicherheitshinweisen und bereit zum Commit.
Rupert ansehen →Was eine DevOps-Konfiguration tatsächlich umfasst
Für Entwickler, die noch nicht umfassend mit DevOps gearbeitet haben, wird der Umfang der Anforderungen an eine gut konfigurierte Bereitstellungsumgebung oft unterschätzt. Eine produktionsreife Einrichtung für eine typische Webanwendung umfasst: Containerisierung (Dockerfile mit Multi-Stage-Build, docker-compose für die lokale Entwicklung und .dockerignore, um die Image-Größe überschaubar zu halten), eine CI/CD-Pipeline (automatisierte Linting-, Test-, Build- und Deployment-Jobs, die durch Branch-Ereignisse ausgelöst werden, mit umgebungsspezifischer Konfiguration und Secret-Management), Infrastructure as Code (Terraform oder ein ähnliches Tool, das die Cloud-Ressourcen in versionskontrollierter Konfiguration statt durch manuelle Klicks in der Konsole definiert), die Einrichtung von Monitoring und Alerting sowie Sicherheitskonfigurationen auf allen Ebenen.
Die meisten Entwicklungsteams verfügen über Fragmente davon - eine funktionierende Dockerfile, eine teilweise eingerichtete CI/CD-Pipeline und teilweise manuell bereitgestellte Infrastruktur. Rupert schließt die Lücken und liefert die vollständige, produktionsreife Version jeder Komponente für den jeweils verwendeten Stack und die jeweilige Plattform.
Was Rupert für jeden Konfigurationstyp erstellt
Docker und Containerisierung. Ein produktionsbereites Dockerfile mit einem mehrstufigen Build (getrennte Build- und Laufzeitstufe, um die Größe des finalen Images zu minimieren), einer Konfiguration für einen Nicht-Root-Benutzer (eine Sicherheitsanforderung, die viele Entwickler überspringen), einer Healthcheck-Definition und einer .dockerignore-Datei. Eine docker-compose-Datei für lokale Entwicklung und Tests. Inline-Kommentare, die jede nicht offensichtliche Entscheidung erläutern. Ein Build- und Testbefehl, mit dem die Konfiguration lokal vor dem Push überprüft werden kann.
CI/CD-Pipelines. Eine vollständige GitHub-Actions- oder GitLab-CI-YAML-Datei, die die gesamte Pipeline abdeckt: Linting und statische Analyse, Unit- und Integrationstests, Sicherheitsüberprüfung, Erstellung und Übertragung des Images in die Registry sowie Bereitstellung in der Zielumgebung. Umgebungsspezifische Konfiguration für Staging und Produktion mit Anweisungen zur Geheimnisverwaltung, die auf die verwendete Plattform zugeschnitten sind. Bedingte Bereitstellungslogik - Bereitstellung in Staging beim Zusammenführen eines PRs, Bereitstellung in Produktion bei einem Release-Tag - mit Rollback-Konfiguration.
Infrastructure as Code. Terraform-Module mit der standardmäßigen Struktur (main.tf, variables.tf, outputs.tf), Remote-State-Konfiguration für die Teamnutzung und umgebungsspezifischen Variablendateien. Für AWS, GCP oder Azure - je nachdem, was das Team verwendet - mit den für den Anwendungstyp geeigneten spezifischen Ressourcentypen und Konfigurationen. Ein Prüfprozess für Destroy-Pläne, um das versehentliche Löschen von Infrastruktur zu verhindern.
Kubernetes-Manifeste. Deployment-, Service-, ConfigMap- und Ingress-Ressourcen für containerisierte Anwendungen. Ressourcenlimits und -anforderungen, um Speicher- und CPU-Probleme in gemeinsam genutzten Clustern zu verhindern. Konfiguration von Liveness- und Readiness-Probes. Konfiguration des horizontalen Pod-Autoscalers für Anwendungen mit variablem Datenverkehr.
Sicherheit von Anfang an statt nachträglich hinzugefügt
Sicherheit in der Infrastrukturkonfiguration ist keine separate Phase - sie besteht aus einer Reihe von Entscheidungen, die während der Ersteinrichtung getroffen werden und entweder Schwachstellen schaffen oder verhindern. Die Entscheidungen, die am häufigsten ausgelassen und am häufigsten ausgenutzt werden, sind vorhersehbar: fest in Konfigurationsdateien codierte Geheimnisse, IAM-Rollen mit übermäßig weitreichenden Berechtigungen, Container-Images, die als Root ausgeführt werden, eine über den erforderlichen Umfang hinausgehende Netzwerkfreigabe und eine fehlende Image-Überprüfung in der CI-Pipeline.
Jede Rupert-Ausgabe enthält einen Abschnitt „Sicherheitshinweise“, der die für diese Konfiguration spezifischen Sicherheitsaspekte behandelt: welche Werte in einer Geheimnisverwaltung statt im Repository gespeichert werden müssen, welche minimal erforderlichen IAM-Berechtigungen die Bereitstellungsrolle benötigt, welche Netzwerkports eingeschränkt werden sollten und welche Integration zur Image-Überprüfung für die verwendete CI-Plattform empfohlen wird. Dies sind die Konfigurationen, die Entwicklungsteams unter Zeitdruck am häufigsten zurückstellen - und diejenigen, die in Produktionsumgebungen die schwerwiegendsten Sicherheitsvorfälle verursachen.
Plattformspezifische Konfiguration statt allgemeiner Vorlagen
Allgemeine DevOps-Vorlagen sind ein Ausgangspunkt, der umfangreiche Anpassungen erfordert, um in einer bestimmten Umgebung zu funktionieren. Das Deployment einer Node.js-Anwendung auf AWS ECS erfordert anderes Terraform, eine andere CI/CD-Konfiguration und eine andere Einrichtung der Zustandsprüfungen als das Deployment derselben Anwendung auf Google Cloud Run. GitHub Actions hat eine andere Syntax, andere Trigger-Mechanismen und ein anderes Geheimnismanagement als GitLab CI. Eine AWS-IAM-Rollenkonfiguration unterscheidet sich in sicherheits- und funktionsrelevanter Hinsicht von einer GCP-Dienstkontokonfiguration.
Rupert fragt während der Aufnahme nach dem Cloud-Anbieter, der CI/CD-Plattform, der Laufzeitumgebung und dem Deployment-Ziel - und erstellt eine für diese Kombination spezifische Konfiguration. Die Ausgabe setzt nicht voraus, dass der Entwickler versteht, wie eine allgemeine Vorlage an die eigene Umgebung angepasst wird; sie funktioniert direkt für die jeweilige Umgebung.
Für Entwickler ohne DevOps-Hintergrund
Rupert ist besonders wertvoll für Full-Stack-Entwickler, die gute Software entwickeln, aber nur wenig Erfahrung mit Infrastruktur haben - eine Kategorie, zu der die Mehrheit der Entwickler in Unternehmen ohne eigene DevOps-Ingenieure gehört. Der agent erklärt jede wichtige Architekturentscheidung in der Ausgabe: warum mehrstufige Docker-Builds die Image-Größe reduzieren, indem sie Build-Abhängigkeiten vom Laufzeit-Image trennen; warum das Ausführen von Containern ohne Root-Rechte bei Container-Escape-Szenarien wichtig ist; warum Blue-Green-Deployments Ausfallzeiten beim Deployment vermeiden; und warum ein entfernter Terraform-Statusdatei Konflikte zwischen Statusdateien in Teamumgebungen verhindert.
Die Erklärungen sind auf Entwickler zugeschnitten, die Code und Systeme im Allgemeinen verstehen, sich aber speziell in der Infrastrukturkonfiguration weiterbilden. Die Ausgabe baut Kompetenz auf, statt lediglich Konfiguration zu liefern - damit Entwickler die von Rupert erstellten Ergebnisse selbst warten und erweitern können, ohne für jede Änderung zum agent zurückkehren zu müssen.
So starten Sie eine DevOps-Sitzung mit Rupert
Laden Sie die Rupert-Skill-Datei in Claude Projects. Fügen Sie den Aktivierungs-Prompt ein. Rupert stellt nacheinander Fragen zur Anwendung: zum Anwendungstyp, zur Sprache und zum Framework, zum Cloud-Anbieter, zur CI/CD-Plattform, zum Deployment-Ziel sowie zu spezifischen Anforderungen oder Einschränkungen. Antworten Sie konkret - je präziser die Angaben zum Stack sind, desto genauer ist die Ausgabe. Erhalten Sie vollständige, sofort commit-fertige Konfigurationsdateien mit Implementierungsanweisungen. Rupert funktioniert mit Claude, ChatGPT oder jedem AI-Chat, der System-Prompts akzeptiert. Für Teams mit komplexen Setups über mehrere Umgebungen hinweg sorgt ein separates Claude Project pro Umgebung dafür, dass die Konfigurationen übersichtlich und unabhängig voneinander aktualisierbar bleiben.