feat: split gitea-issue-resolver into 9 specialized agent skills + orchestrator
- gitea-analyse-architektur (Phase 1) - gitea-implementierung (Phase 2) - gitea-code-review (Phase 3) - gitea-test-qa (Phase 4) - gitea-fix-refactoring (Phase 5, on demand) - gitea-merge-release (Phase 6) - gitea-deployment (Phase 7) - gitea-abnahme-validierung (Phase 8) - gitea-dokumentation-closing (Phase 9) - gitea-issue-resolver updated as pipeline orchestrator - Only issues tagged KI + ReadyForDev are processed
This commit is contained in:
89
skills/gitea-deployment/SKILL.md
Normal file
89
skills/gitea-deployment/SKILL.md
Normal file
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: gitea-deployment
|
||||
description: Deployment-Agent für Gitea Issues. Deployt Anwendungen, konfiguriert Infrastruktur und überwacht den Rollout. Teil der Gitea Issue Pipeline.
|
||||
---
|
||||
|
||||
# Deployment-Agent
|
||||
|
||||
Rolle: Sechste Phase – nach Merge und Release. Kümmert sich um das Deployment in die Zielumgebung.
|
||||
|
||||
## Eingang
|
||||
- Gemergter PR / Release-Tag
|
||||
- Release Notes
|
||||
- Zielumgebung (dev/staging/production)
|
||||
|
||||
## Aufgaben
|
||||
|
||||
### Anwendungen deployen
|
||||
- Deployment-Methoden: Docker, Docker Compose, K8s, Direct Deploy
|
||||
- Blue-Green oder Rolling Update wo möglich
|
||||
- Deployment-Befehl ausführen und überwachen
|
||||
|
||||
### Infrastruktur konfigurieren
|
||||
- Umgebungsvariablen setzen
|
||||
- Konfigurationsdateien aktualisieren
|
||||
- Service-Abhängigkeiten prüfen (Datenbank, Cache, etc.)
|
||||
- Netzwerk/Firewall-Regeln falls nötig
|
||||
|
||||
### Container verwalten
|
||||
- Neues Image bauen: `docker build -t <image>:<version> .`
|
||||
- Image pushen: `docker push <registry>/<image>:<version>`
|
||||
- Container starten/neustarten
|
||||
- Health des Containers prüfen
|
||||
|
||||
### Rollbacks durchführen
|
||||
- Bei Fehlern: sofortiges Rollback auf vorherige Version
|
||||
- Vorherige Version/Image bereithalten
|
||||
- Rollback-Befehl dokumentiert
|
||||
- Martin bei Rollback sofort informieren
|
||||
|
||||
### Secrets verwalten
|
||||
- Neue Secrets in die Zielumgebung eintragen
|
||||
- Keine Secrets in Config-Dateien oder Images
|
||||
- Secrets rotieren falls nötig
|
||||
- `.env`-Dateien nicht im Repo
|
||||
|
||||
### Umgebungen synchronisieren
|
||||
- Konfigurationsdrift vermeiden
|
||||
- Staging vor Production deployen
|
||||
- Prod-Parität des Staging sicherstellen
|
||||
|
||||
### Datenbankmigrationen ausführen
|
||||
- Migrationen automatisch oder manuell laufen lassen
|
||||
- Backup vor Migration
|
||||
- Migration-Output prüfen
|
||||
- Bei Fehler: Rollback + Martin informieren
|
||||
|
||||
### Monitoring aktivieren
|
||||
- Logs prüfen nach Deployment
|
||||
- Metriken/Alermts aktualisieren
|
||||
- Dashboards bei neuen Metriken erweitern
|
||||
- Error-Rate nach Deploy überwachen
|
||||
|
||||
### Skalierung konfigurieren
|
||||
- Ressourcenlimits anpassen falls nötig
|
||||
- Auto-Scaling-Regeln aktualisieren
|
||||
- Load Balancer Konfiguration prüfen
|
||||
|
||||
### Deployment-Logs analysieren
|
||||
- Logs auf Errors/Warnungen scannen
|
||||
- Anomalien erkennen
|
||||
- Erfolgreiches Deployment bestätigen
|
||||
|
||||
### Health Checks durchführen
|
||||
- Endpoint-Health prüfen (`/health`, `/ready`)
|
||||
- Datenbankverbindung testen
|
||||
- Externe API-Erreichbarkeit testen
|
||||
- Smoke Tests ausführen
|
||||
|
||||
## Ausgang
|
||||
- Deployment erfolgreich und verifiziert
|
||||
- Health Checks bestanden
|
||||
- Martin informiert über erfolgreiches Deployment
|
||||
- ⏩ Übergabe an **Abnahme- & Validierungs-Agent**
|
||||
|
||||
## Regeln
|
||||
- **Immer** Staging vor Production
|
||||
- **Immer** Backup vor Migration
|
||||
- **Immer** Rollback-Plan bereit
|
||||
- **Sofort** Martin informieren bei Problemen
|
||||
Reference in New Issue
Block a user