Die Infrastruktur-Lücke, die die meisten Entwicklungsteams haben
In Entwicklungsteams ohne eigenen DevOps Engineer zeigt sich ein wiederkehrendes Muster: Anwendungen werden gut entwickelt und schlecht bereitgestellt. Der Code ist sauber, getestet und geprüft. Die Docker-Einrichtung wurde notdürftig aus einem Tutorial übernommen, das für einen anderen Stack geschrieben wurde. Die CI/CD-Pipeline existiert entweder 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 für die Wiederherstellung benötigen.
Jede Bereitstellung unter diesen Bedingungen birgt Risiken. Eine fehlgeschlagene Bereitstellung bei Spitzenverkehr verursacht Ausfallzeiten. Eine falsche Sicherheitskonfiguration in der Infrastruktur setzt die Anwendung Schwachstellen aus, die eine ordnungsgemäß konfigurierte Pipeline vor der Bereitstellung erkennen würde. Fehlt ein Health Check, erhält ein fehlerhafter Container weiterhin Traffic. Keines dieser Probleme ist schwer zu lösen - es sind Probleme, die DevOps-Wissen erfordern, über das das Team nicht verfügt, sowie 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 anzupassenden Vorlagen, sondern Dateien, die bereit zum Commit in das Repository, getestet und bereitgestellt sind.
Rupert erstellt deine Dockerfiles, CI/CD-Pipelines und Terraform-Module - produktionsbereit, mit Sicherheitshinweisen und bereit zum Commit.
Rupert anzeigen →Was die 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 mehrstufigem Build, docker-compose für die lokale Entwicklung und .dockerignore, um die Image-Größe überschaubar zu halten), eine CI/CD-Pipeline (automatisierte Lint-, Test-, Build- und Deployment-Jobs, die durch Branch-Ereignisse ausgelöst werden, mit umgebungsspezifischer Konfiguration und Geheimnisverwaltung), Infrastructure as Code (Terraform oder eine ähnliche Lösung, die die Cloud-Ressourcen in versionierter Konfiguration statt durch manuelle Klicks in der Konsole definiert), die Einrichtung von Monitoring und Alarmierung sowie Sicherheitskonfiguration auf allen Ebenen.
Die meisten Entwicklungsteams verfügen über Fragmente davon - eine funktionierende Dockerfile, eine teilweise eingerichtete CI/CD-Pipeline und eine 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 verwendete Plattform.
Was Rupert für jeden Konfigurationstyp erstellt
Docker und Containerisierung. Eine produktionsreife Dockerfile mit Multi-Stage-Build (getrennte Build- und Laufzeitstufe zur Minimierung der Größe des finalen Images), Konfiguration eines Nicht-Root-Benutzers (eine Sicherheitsanforderung, die viele Entwickler überspringen), Definition eines Healthchecks und eine .dockerignore-Datei. Eine docker-compose-Datei für lokale Entwicklung und Tests. Inline-Kommentare, die jede nicht offensichtliche Entscheidung erklären. Ein Build- und Testbefehl, um die Konfiguration lokal vor dem Push zu überprüfen.
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, Image-Erstellung und -Push in die Registry sowie Deployment in die Zielumgebung. Umgebungsspezifische Konfiguration für Staging und Produktion mit Anweisungen zur Geheimnisverwaltung, die auf die verwendete Plattform zugeschnitten sind. Bedingte Deployment-Logik - Deployment nach dem Zusammenführen eines PR in Staging, Deployment nach einem Release-Tag in Produktion - mit Rollback-Konfiguration.
Infrastructure as Code. Terraform-Module in der Standardstruktur (main.tf, variables.tf, outputs.tf), eine Remote-State-Konfiguration für die Teamnutzung und umgebungsspezifische 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 den Destroy-Plan, um versehentliches 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 eines Horizontal Pod Autoscalers für Anwendungen mit variablem Datenverkehr.
Sicherheit von Anfang an, nicht 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 Sicherheitslücken schaffen oder verhindern. Die Entscheidungen, die am häufigsten ausgelassen und am häufigsten ausgenutzt werden, sind vorhersehbar: fest in Konfigurationsdateien hinterlegte Geheimnisse, IAM-Rollen mit übermäßig weitreichenden Berechtigungen, Container-Images, die als Root ausgeführt werden, eine über das Erforderliche 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 der Geheimnisverwaltung statt im Repository gespeichert werden müssen, welche IAM-Berechtigungen mindestens für die Deployment-Rolle erforderlich sind, 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 der Produktion die schwerwiegendsten Sicherheitsvorfälle verursachen.
Plattformspezifische Konfiguration statt generischer Vorlagen
Generische 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 eine andere Verwaltung von Secrets als GitLab CI. Die Konfiguration einer AWS-IAM-Rolle unterscheidet sich von der Konfiguration eines GCP-Servicekontos in sicherheits- und funktionsrelevanten Punkten.
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 weiß, wie eine generische Vorlage an seine Umgebung angepasst wird; sie funktioniert direkt in seiner Umgebung.
Für Entwickler ohne DevOps-Hintergrund
Rupert ist besonders wertvoll für Full-Stack-Entwickler, die gute Software entwickeln, aber nur begrenzte Infrastrukturkenntnisse haben - eine Gruppe, 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 als Nicht-Root-Benutzer bei Container-Escape-Szenarien wichtig ist, warum Blue/Green-Deployments Ausfallzeiten beim Deployment vermeiden und warum ein entfernter Terraform-Status Konflikte bei Statusdateien in Teamumgebungen verhindert.
Die Erklärungen sind auf Entwickler zugeschnitten, die Code und Systeme allgemein verstehen, aber gerade lernen, wie Infrastrukturkonfigurationen funktionieren. Die Ausgabe baut Kompetenz auf, statt nur Konfigurationen zu liefern - so können Entwickler die von Rupert erstellten Ergebnisse selbst warten und erweitern, ohne für jede Änderung zum agent zurückkehren zu müssen.
So startest du eine DevOps-Sitzung mit Rupert
Lade die Rupert-Skill-Datei in Claude Projects. Füge den Aktivierungs-prompt ein. Rupert stellt nacheinander Fragen zur Aufnahme: zum Anwendungstyp, zur Sprache und zum Framework, zum Cloud-Anbieter, zur CI/CD-Plattform, zum Deployment-Ziel sowie zu spezifischen Anforderungen oder Einschränkungen. Antworte konkret - je präziser die Angaben zum Stack sind, desto genauer ist die Ausgabe. Erhalte vollständige, commitfertige Konfigurationsdateien mit Implementierungsanweisungen. Rupert funktioniert mit Claude, ChatGPT oder jedem anderen AI-Chat, der System-prompts akzeptiert. Für Teams mit komplexen Umgebungen mit mehreren Stages sorgt ein separates Claude Project pro Umgebung dafür, dass die Konfigurationen übersichtlich und unabhängig aktualisierbar bleiben.
