Zum Inhalt

đŸ€– ErklĂ€ren mit KI

Konfigurieren automatisierter QualitÀtssicherung und Sicherheitsleitplanken

Übersicht

Jeder von der 4Geeks AI Factory generierte Code durchlĂ€uft ein automatisiertes Quality Gate, bevor er jemals von einem menschlichen Entwickler ĂŒberprĂŒft wird. Dieses Gate fĂŒhrt sofortige Schwachstellenscans und KI-gesteuerte Komponententests durch und stellt so sicher, dass die Geschwindigkeit niemals die Sicherheit beeintrĂ€chtigt.

In diesem Tutorial lernen Sie:

  • Wie das Quality Gate funktioniert
  • Welche Sicherheitsscans werden durchgefĂŒhrt? – Wie Unit-Tests automatisch generiert werden
  • So konfigurieren Sie QA-Regeln fĂŒr Ihr Projekt
  • Wie man Quality Gate-Ergebnisse interpretiert

Die Quality Gate-Pipeline

AI-Generated Code
    │
    ▌
┌─────────────────────────────────┐
│         QUALITY GATE            │
│                                 │
│  1. Static Code Analysis        │
│  2. Vulnerability Scanning      │
│  3. AI-Generated Unit Tests     │
│  4. Code Style Validation       │
│  5. Performance Analysis        │
│  6. Dependency Audit            │
│                                 │
│  ┌─────────┐    ┌─────────┐    │
│  │  PASS   │───â–ș│  FAIL   │    │
│  └─────────┘    └─────────┘    │
└────────┬───────────────┬───────┘
         │               │
         ▌               ▌
  Human Review     Auto-Fix & Retry
  (Senior Arch)    (up to 2 attempts)

Schritt 1: Die Scans verstehen

1. Statische Code-Analyse

  • Was ĂŒberprĂŒft wird: CodequalitĂ€t, KomplexitĂ€t, Wartbarkeit
  • Verwendete Tools: ESLint, Pylint, SonarQube (sprachabhĂ€ngig)
  • Durchgesetzte Regeln: Die Codierungsstandards Ihres Projekts + Best Practices der Branche
  • Ausgabe: QualitĂ€tsbewertung (A-F) mit konkreten VerbesserungsvorschlĂ€gen

2. Schwachstellenscan

  • Was ĂŒberprĂŒft wird: OWASP Top 10, CWE-Schwachstellen, Injektionsrisiken
  • Verwendete Tools: Snyk, Semgrep, CodeQL
  • Abdeckung: SQL-Injection, XSS, CSRF, Authentifizierungsfehler, unsichere AbhĂ€ngigkeiten
  • Ausgabe: Schwachstellenbericht mit Schweregradbewertung (Kritisch, Hoch, Mittel, Niedrig)

3. KI-generierte Unit-Tests

  • Was es tut: Generiert automatisch Komponententests fĂŒr neuen Code
  • Abdeckungsziel: Mindestens 80 % Codeabdeckung fĂŒr neuen Code
  • Test-Framework: Jest (JavaScript/TypeScript), pytest (Python), JUnit (Java)
  • Ausgabe: Testdateien mit Behauptungen, RandfĂ€llen und Fehlerszenarien

4. Validierung des Codestils

  • Was ĂŒberprĂŒft wird: Formatierung, Namenskonventionen, Dateiorganisation
  • Verwendete Tools: Prettier, Black, gofmt (sprachabhĂ€ngig)
  • Regeln: Der konfigurierte Styleguide Ihres Projekts
  • Ausgabe: Automatisch formatierter Code- oder Stilverletzungsbericht

5. Leistungsanalyse

  • Was ĂŒberprĂŒft wird: ZeitkomplexitĂ€t, Speichernutzung, N+1 Abfragen
  • Erkennung: Ineffiziente Schleifen, unbegrenzte Rekursion, fehlende Indizes
  • Ausgabe: Leistungswarnungen mit OptimierungsvorschlĂ€gen

6. AbhĂ€ngigkeitsprĂŒfung

  • Was ĂŒberprĂŒft wird: Bekannte Schwachstellen in AbhĂ€ngigkeiten
  • Datenbank: NVD, GitHub Advisory Database, Snyk Vulnerability DB
  • Ausgabe: Liste der anfĂ€lligen AbhĂ€ngigkeiten mit Upgrade-Empfehlungen

Schritt 2: QA-Regeln konfigurieren

Zugriff auf QA-Einstellungen

  1. Gehen Sie zu den KI-Werkseinstellungen Ihres Projekts.
  2. Navigieren Sie zu Quality Gate-Konfiguration

Scanregeln konfigurieren

Einstellung Optionen Standard
MindestqualitÀtswert A, B, C, D, F B
Kritische Schwachstellen blockieren Ja/Nein Ja
Bei hohen Schwachstellen blockieren Ja/Nein Ja
Mindesttestabdeckung 0-100 % 80 %
StilverstĂ¶ĂŸe automatisch beheben Ja/Nein Ja
Max. Wiederholungsversuche 1-5 2

Benutzerdefinierte Regeln

Projektspezifische Regeln hinzufĂŒgen:

custom_rules:
  # Require JSDoc comments on all public functions
  - rule: require-jsdoc
    severity: warning
    pattern: "export (function|class)"

  # No console.log in production code
  - rule: no-console-log
    severity: error
    pattern: "console\\.log"
    exclude:
      - "**/*.test.*"
      - "**/debug/**"

  # Maximum function length
  - rule: max-function-length
    severity: warning
    max_lines: 50

Schritt 3: Quality-Gate-Ergebnisse interpretieren

Passierendes Tor

✅ Quality Gate PASSED

Quality Score:    A (95/100)
Vulnerabilities:  0 Critical, 0 High, 1 Medium, 2 Low
Test Coverage:    87% (target: 80%)
Style Issues:     0 (auto-fixed: 3)
Performance:      No issues detected
Dependencies:     All up to date

→ Ready for Human Review

Fehlerhaftes Tor

❌ Quality Gate FAILED

Quality Score:    C (72/100)
Vulnerabilities:  1 High (SQL injection risk in line 42)
Test Coverage:    65% (target: 80%)
Style Issues:     12 (auto-fixed: 8, remaining: 4)
Performance:      1 warning (N+1 query in getUserOrders)
Dependencies:     2 vulnerable packages found

→ Auto-fixing (attempt 1 of 2)

Nach der automatischen Korrektur

✅ Quality Gate PASSED (after auto-fix)

Quality Score:    B (85/100) — improved from C
Vulnerabilities:  0 Critical, 0 High — SQL injection fixed
Test Coverage:    82% — improved from 65%
Style Issues:     0 — all auto-fixed
Performance:      1 warning remains (manual review needed)
Dependencies:     2 packages updated

→ Ready for Human Review

Schritt 4: Behandeln Sie Quality-Gate-Fehler

Wenn das Gate nach allen Wiederholungsversuchen fehlschlÀgt:

  1. Der Code ist zur manuellen ÜberprĂŒfung markiert
  2. Ihr leitender Architekt erhÀlt einen detaillierten Bericht
  3. Der Architekt behebt die verbleibenden Probleme
  4. Code wird erneut ĂŒber das Gate ĂŒbermittelt
  5. Nach dem Bestehen wird die PR erstellt

HĂ€ufige FehlergrĂŒnde

Fehler Typische Ursache Auflösung
Geringe Testabdeckung Komplexe Verzweigungslogik Architekt fĂŒgt Randfalltests hinzu
Hohe Verwundbarkeit Unsichere Eingabeverarbeitung Architekt fĂŒhrt Desinfektion durch
StilverstĂ¶ĂŸe Nicht standardmĂ€ĂŸige Muster Automatische Korrektur oder manuelle Formatierung
Leistungsprobleme Ineffiziente Algorithmen Architekt optimiert den Code
AbhÀngigkeitsschwachstellen Veraltete Pakete Architect aktualisiert AbhÀngigkeiten

Best Practices

Geeignete Schwellenwerte festlegen

  • Strikt beginnen: Höhere Schwellenwerte erkennen mehr Probleme frĂŒhzeitig
  • Anpassung je nach Projekt: Kritische Systeme benötigen strengere Regeln
  • Geschwindigkeit vs. QualitĂ€t ausbalancieren: Zu streng = langsamere Lieferung
  • Monatliche ÜberprĂŒfung: Passen Sie die Schwellenwerte basierend auf Fehlermustern an

Security-First-Ansatz

  • Deaktivieren Sie niemals das Scannen auf Schwachstellen
  • Immer bei kritischen und hohen Schwachstellen blockieren
  • ÜberprĂŒfen Sie wöchentlich mittlere Schwachstellen
  • AbhĂ€ngigkeitsprĂŒfungen automatisiert halten

TestqualitÀt

  • Konzentrieren Sie sich auf eine sinnvolle Abdeckung: 80 % des wichtigen Codes > 100 % von allem
  • RandfĂ€lle einbeziehen: Nulleingaben, Grenzwerte, Fehlerpfade
  • Integrationspunkte testen: API-Aufrufe, Datenbankabfragen, externe Dienste
  • ÜberprĂŒfen Sie automatisch generierte Tests: Stellen Sie sicher, dass sie echtes Verhalten testen, nicht nur Codepfade

Was kommt als nÀchstes?

Brauchen Sie Hilfe?


Noch Fragen? Get support or explore tutorials