greggy/openclaw
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
db82c851b5216d95c014cdcda70aad8fc05949be
openclaw/skills/gitea-deployment/SKILL.md
OpenClaw db82c851b5 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
2026-05-10 20:18:24 +00:00

2.6 KiB
Raw Blame History

name, description
name description
gitea-deployment 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