WERBEPLATZ VERFÜGBAR · PARTNERSCHAFTEN WILLKOMMEN

Wie Software-Engineering-Teams Sweep konfigurieren, um GitHub Issues in automatisierte Bugfix-Pull-Requests zu verwandeln

365Finds Editorial
11.430 Wiki-Artikel erfasst

365 Wiki mit deiner KI nutzen

Kopiere den Prompt unten, füge ihn in deine gewohnte KI ein und stelle direkt deine Frage.

Vollständigen Skill herunterladen

Probiere es zuerst mit dem Prompt aus. Wenn du 365 Wiki häufig nutzt, installiere den vollständigen 365Wiki Skill, damit du ihn nicht jedes Mal einfügen musst. Ohne bevorzugte KI funktionieren auch die Webversionen von Gemini oder Microsoft Copilot.

In der modernen Softwareentwicklung bindet die Behebung von Routinefehlern und kleineren Wartungsaufgaben erhebliche Kapazitäten erfahrener Ingenieure. Null-Pointer-Prüfungen, Anpassungen an veraltete Bibliotheken, Regex-Korrekturen und das Nachreichen fehlender Unit-Tests bleiben häufig wochenlang im Backlog liegen, weil Senior-Entwickler mit geschäftskritischen Produktfeatures ausgelastet sind.

Sweep wurde konzipiert, um genau diese Lücke als autonomer KI-Entwickler (AI Junior Developer) zu schließen. Als GitHub App in ein Repository integriert, überwacht Sweep eingehende Issues, analysiert den Codebestand mithilfe von Vektor-Embeddings und AST-Parsing (Abstract Syntax Tree), erstellt Anpassungen über mehrere Dateien hinweg und öffnet strukturierte Pull Requests (PRs). Darüber hinaus schließt Sweep den Regelkreis, indem es Testfehler in GitHub Actions auswertet, um sich selbst zu korrigieren, und direkt auf Inline-Code-Reviews von menschlichen Entwicklern reagiert.

Dieser Leitfaden erläutert praxisnah, wie Entwicklungsteams Sweep einrichten, die Konfigurationsdatei sweep.yaml für Produktionsumgebungen anpassen, präzise Issue-Prompts formulieren und essenzielle Sicherheitsrichtlinien etablieren.


1. Der Workflow: Vom GitHub Issue zum Pull Request

Vor der Konfiguration muss das Team den Lebenszyklus eines von Sweep bearbeiteten Tickets verstehen:

  1. Auslösendes Ereignis: Ein Entwickler erstellt ein GitHub Issue mit dem Präfix Sweep: (z. B. Sweep: Fix KeyError when user metadata payload is missing), weist dem Issue das Label sweep zu oder erwähnt @sweepai in einem Kommentar.
  2. Kontextsuche im Repository: Die Webhook-Funktion von Sweep (on_ticket) wird aufgerufen. Sie nutzt semantische Vektorsuche und AST-Chunking, um betroffene Dateien, Klassen, Funktionen und vorhandene Tests zu identifizieren.
  3. Erstellung des Ausführungsplans: Sweep hinterlässt einen interaktiven Kommentar im Issue, der die beabsichtigte Vorgehensweise und die Liste der zu modifizierenden Dateien darlegt.
  4. Codegenerierung und Branching: Auf einem isolierten Branch (z. B. sweep/fix-...) nimmt Sweep die Änderungen gemäß den Vorgaben des Projekts vor und pusht die Commits.
  5. Erstellung des Pull Requests: Sweep öffnet einen regulären PR mit Verknüpfung zum gelösten Ticket (Fixes #<id>), einer Zusammenfassung der Änderungen und einer Checkliste.
  6. Kontinuierlicher Feedback-Loop:
    • CI-Selbstkorrektur: Bei aktivierter GitHub Actions-Integration (gha_enabled: true) liest Sweep bei fehlschlagenden Tests die Fehlermeldungen aus und pusht selbstständig Reparatur-Commits.
    • Menschliches Code-Review: Hinterlässt ein Entwickler Inline-Kommentare im Diff des PRs, analysiert Sweep das Feedback und aktualisiert den Code umgehend.

2. Installation und Berechtigungen in GitHub

Um Sweep für ein Repository oder eine Organisation freizugeben:

  1. GitHub App installieren: Rufen Sie die Installationsseite der Sweep GitHub App auf und wählen Sie die gewünschten Repositories aus.
  2. Erforderliche Berechtigungen gewähren:
    • Repository Contents (Lesen und Schreiben): Erforderlich zum Auslesen des Quellcodes und zum Erstellen von Branches und Commits.
    • Issues (Lesen und Schreiben): Erforderlich zum Lesen von Fehlerbeschreibungen, Verwalten von Labels und Verfassen von Statuskommentaren.
    • Pull Requests (Lesen und Schreiben): Erforderlich zum Eröffnen von PRs, Analysieren von Diffs und Verarbeiten von Review-Kommentaren.
    • Actions / Checks (Lesen): Erforderlich zum Abrufen von CI-Protokollen bei fehlgeschlagenen Testläufen.
  3. Draft-Status einrichten: In der Einführungsphase empfiehlt es sich, PRs zunächst als Entwurf (draft: true) erstellen zu lassen, um unnötige Benachrichtigungen in Team-Kanälen zu vermeiden, bis der Lösungsansatz geprüft wurde.

3. Repository-Regeln mit sweep.yaml steuern

Das Verhalten von Sweep wird maßgeblich über die Konfigurationsdatei sweep.yaml (oder .sweep/config.yaml) im Stammverzeichnis des Repositories bestimmt. Eine fundierte Konfiguration verhindert Halluzinationen bei Importen, erzwingt Teamstandards und schützt sensible Bereiche.

Vorlage für eine produktive sweep.yaml

# sweep.yaml - Konfiguration für die automatisierte Issue-Bearbeitung

# Ziel-Branch, von dem Sweep abzweigt und gegen den PRs geöffnet werden
branch: 'main'

# PRs als Entwurf öffnen (für neue Teams empfohlen)
draft: false

# Aktiviert das Auslesen von GitHub Actions-Fehlern zur automatischen Nachbesserung
gha_enabled: true

# Projektüberblick zur optimalen Orientierung der KI-Modelle
description: >
  Backend-REST-API, entwickelt mit Python 3.10 und FastAPI.
  Die Datenbankinteraktion basiert auf SQLAlchemy 2.0 und PostgreSQL.
  Geschäftslogik liegt in services/, Modelle in models/ und Endpunkte in api/v1/.
  Alle Modulimporte müssen absolut sein (z. B. `from services.auth import verify_token`).

# Verzeichnisse und Dateien, die Sweep NIEMALS lesen oder verändern darf
blocked_dirs:
  - "deploy/"
  - "terraform/"
  - ".github/workflows/"
  - "migrations/"
  - "*.env*"
  - "security/"

# Sandbox-Befehle, die vor der PR-Erstellung in einem isolierten Container laufen
sandbox:
  install:
    - "poetry install --no-root"
  check:
    - "poetry run ruff check {file_path}"
    - "poetry run pytest tests/unit"

# Verbindliche Coding-Standards, die in den Agenten-Prompt injiziert werden
rules:
  - "Jeder Bugfix muss entsprechende pytest-Unit-Tests in tests/ ergänzen oder aktualisieren."
  - "Wildcard-Importe (`from module import *`) sind strikt untersagt."
  - "Für Validierungen von API-Requests und -Responses sind Pydantic v2-Schemas zu verwenden."
  - "Verwende loguru für Logging; in Exception-Blöcken muss logger.exception() für Tracebacks genutzt werden."
  - "Ohne ausdrückliche Anweisung dürfen weder Datenbankschemata geändert noch alembic-Migrationen erstellt werden."
  - "Alle neuen oder modifizierten Funktionssignaturen müssen vollständige Typ-Annotationen enthalten."

Die wichtigsten Direktiven im Detail


4. Präzise Issue-Beschreibungen für fehlerfreie PRs verfassen

Die Qualität des von Sweep gelieferten Codes hängt direkt von der Vollständigkeit und Klarheit des GitHub Issues ab. Während Kollegen Rückfragen im Chat stellen können, stützt sich der KI-Agent ausschließlich auf den Text und den Codebestand.

Aufbau eines vorbildlichen Bug-Reports

Titel: Sweep: Fix 400 Bad Request on empty user metadata payload in /api/v1/profile

### Fehlerbeschreibung
Bei der Aktualisierung eines Benutzerprofils über `PUT /api/v1/profile` löst die Übergabe eines leeren Dictionarys `{}` in `metadata` einen ValidationError aus, anstatt die Standardwerte zu übernehmen.

### Schritte zur Reproduktion
1. Sende einen PUT-Request an `/api/v1/profile` mit dem Body `{"metadata": {}}`.
2. Die API antwortet mit HTTP 400 und der Meldung `Value error, metadata must contain required fields`.

### Erwartetes Verhalten
Ein leeres `metadata`-Objekt muss akzeptiert, mit den Default-Werten (`{"theme": "light", "notifications": true}`) initialisiert und gespeichert werden.

### Relevante Dateien und Funktionen
- `api/v1/profile.py`: Handler-Funktion `update_profile`.
- `schemas/profile.py`: Pydantic-Modell `UserProfileUpdate`.
- `services/profile_service.py`: Hilfsfunktion `save_profile_metadata`.

### Akzeptanzkriterien
- Validierung in `schemas/profile.py` so anpassen, dass leere Dictionaries mit Standardwerten durchlaufen.
- Einen Unit-Test in `tests/unit/test_profile_api.py` hinzufügen, der diesen Fall abdeckt.
- Sicherstellen, dass alle bestehenden Tests in `tests/unit/` erfolgreich durchlaufen.

Titelpräfixe zur Steuerung der Ausführung

Der Parser von Sweep (strip_sweep) unterstützt spezifische Präfixe zur Feinsteuerung:


5. Review-Schleife und interaktive Optimierung

Nachdem Sweep den Pull Request eröffnet hat, erfolgt die weitere Interaktion nahtlos in GitHub:

[GitHub Issue] ──> Sweep startet ──> PR erstellt ──> CI (GitHub Actions)
                                                           │
                        ┌──────────────────────────────────┴─────┐
                        ▼                                        ▼
                  CI schlägt fehl (gha_enabled)              CI erfolgreich
                        │                                        │
                        ▼                                        ▼
               Sweep committet Korrektur                     Code-Review durch Entwickler
                        │                                        │
                        └─────────► PR aktualisiert ◄────────────┘
                                         │
                               (Review-Kommentar:
                             "@sweepai nutze bitte die
                               existierende Helper-Funktion")

Inline-Kommentare im Diff

Entwickler müssen den Branch nicht lokal auschecken, um Anpassungen vorzunehmen. Ein einfacher Zeilenkommentar im GitHub PR genügt:

@sweepai Verwende hier bitte unsere Hilfsfunktion DateUtils.formatIso(), anstatt einen neuen Datumsformatierer zu schreiben.

Sweep fängt den Kommentar über Webhooks ab, analysiert den Kontext und pusht einen neuen Commit auf den bestehenden Branch.

Issue neu generieren

Sollte der ursprüngliche Lösungsansatz verworfen werden müssen, reicht es aus, den Titel oder die Beschreibung des ursprünglichen GitHub Issues zu aktualisieren. Sweep erkennt die Änderung, bereinigt den bisherigen Branch und generiert einen neuen PR.


6. Sicherheitsrichtlinien und Grenzen in der Praxis

Für den zuverlässigen Einsatz von autonomen Coding-Agenten im Teamalltag gelten folgende Grundsätze:

  1. Kein Auto-Merge: Aktivieren Sie niemals die automatische Verschmelzung für von Sweep erstellte PRs. Erzwingen Sie über Branch-Schutzregeln mindestens ein manuelles Review durch einen Senior-Entwickler und bestandene CI-Pipelines.
  2. Klare Abgrenzung kritischer Pfade: Schließen Sie über blocked_dirs Infrastrukturdateien (terraform/, k8s/), CI-Workflows (.github/), Datenbankmigrationen und Konfigurationsdateien mit Umgebungsvariablen konsequent aus.
  3. Fokus auf umrissene Aufgaben: Sweep erzielt die besten Ergebnisse bei klar abgegrenzten Bugfixes, Testnachweisen und isolierten Refactorings. Unspezifische Feature-Entwicklungen ohne klare Spezifikation sollten vermieden werden.
  4. Solide Testabdeckung: Die Selbstheilungsfunktion von Sweep steht und fällt mit der Qualität der Testmeldungen. Eine lückenlose Testsuite ist die beste Absicherung gegen unbeabsichtigte Regressionen.

Referenzen