Quality Gates für KI-Code in der Salesforce-Pipeline

KI-generierter Salesforce-Code sollte dieselben Quality Gates bestehen wie Code, den ein Mensch geschrieben hat, unter drei Bedingungen: Jede Prüfung kann eine Änderung stoppen, sie läuft in einer Pipeline, die Ihnen gehört, und sie gilt für jeden Partner gleich. Konkret sind das fünf Prüfungen bei jedem Pull Request, dem Änderungsvorschlag, den ein Entwickler einreicht, bevor Code in den Hauptzweig kommt: Codeanalyse mit fester Schwelle, einige Regeln für typische Fehler von Agenten, ein Testdeployment in eine Sandbox, Performance-Hinweise von ApexGuru und eine Merge-Sperre, die niemand umgehen kann. Was eine Regel nicht entscheiden kann, bleibt beim menschlichen Reviewer.

Rechenbeispiel: Das Ersatzteil ist plötzlich nicht mehr auf Lager

Angenommen sei ein Maschinenbauer mit SAP S/4, Service Cloud, Field Service für 150 Techniker und einem Händlerportal. Zwei Partner, einer onshore und einer nearshore, setzen seit diesem Jahr Coding-Agenten ein. Alle Zahlen sind Annahmen. Die Pull Requests steigen von etwa 60 auf 110 im Monat; auf Kundenseite prüfen weiterhin ein Architekt und ein Release Manager.

Ein Entwickler des Nearshore-Partners lässt einen Agenten einen Rundungsfehler in der Verfügbarkeitsprüfung für Ersatzteile beheben, die Techniker in der mobilen App nutzen. Der Agent behebt ihn, schreibt einen Test und stellt den Code nebenbei auf eine neuere Salesforce-API-Version um. Unter dieser Version sieht der Code nur noch die Datensätze, die der angemeldete Techniker sehen darf. Haben Techniker keinen Zugriff auf den Bestand im Zentrallager, fallen diese Teile aus dem Ergebnis. Der Test läuft nicht als Techniker, also besteht er. Die Codeanalyse ist grün, das Testdeployment ist grün, die Abdeckung liegt bei 91 Prozent.

Diese Prüfung ist ein kurzes Skript, etwa ein Nachmittag Arbeit. Dagegen steht Pipeline-Zeit: Bei 25 Minuten pro Testdeployment sind 110 Läufe rund 46 Stunden im Monat, bezahlt in CI-Minuten, nicht in Kalendern. Warum der Versionswechsel so viel ändert, steht in API 67.0 und User Mode.

Die eigenen Prüfungen des Partners reichen nicht

Der DORA-Report 20251 zeigt: KI-Nutzung erhöht den Durchsatz in der Softwareauslieferung, hängt aber weiterhin negativ mit deren Stabilität zusammen. Die Begründung: Ohne robuste Kontrollsysteme wie automatisierte Tests, ausgereifte Versionskontrolle und schnelle Rückmeldung führt mehr Änderungsvolumen zu Instabilität. In einem Salesforce-Programm ist die Pipeline dieses Kontrollsystem.

Die Salesforce-eigenen Skills für Claude Code prüfen schon auf dem Entwicklerrechner einiges. Laut Salesforce Developers Blog2 lehnen sie Datenbankabfragen in Schleifen ab, führen Code Analyzer und die Apex-Tests aus und sorgen für 75 Prozent Abdeckung, bevor sie fertig melden. Derselbe Beitrag empfiehlt trotzdem, Code Analyzer „manually as an extra safety check“ laufen zu lassen.

Für Sie als Kunde ist eine Prüfung auf dem Laptop eines Partners dessen Wort. Welche Konfiguration lief und welche Regeln abgeschaltet waren, sehen Sie nicht. Maßgeblich ist die Prüfung in einer Pipeline, die Ihnen gehört, mit denselben Schwellen für jeden Partner. Tests ohne Aussage, falsche Felder und Geschäftsregeln brauchen weiterhin einen Menschen; diese Aufteilung beschreibe ich in KI-generierten Salesforce-Code prüfen.

Welche Quality Gates muss KI-generierter Code bestehen?

Ich würde fünf Prüfungen in dieser Reihenfolge laufen lassen, damit die günstigen zuerst scheitern.

Die fünf Prüfungen bei jedem Pull Request

PrüfungWas sie stopptSperrt den Merge?Wem sie gehört

CodeanalyseBekannte Sicherheits- und PerformancefehlerJa, ab Schwere HighKunde legt die Schwelle fest

Regeln für AgentenUngefragte Versionswechsel, fest eingetragene AdressenJaArchitekt des Kunden

TestdeploymentErfundene Felder, fehlende Abhängigkeiten, rote TestsJaPipeline, Integrations-Sandbox

ApexGuruLangsamer Code unter echter LastNein, nur BerichtRelease Manager je Release

Merge-SperreMerge eines roten Builds, auch durch AdminsJaCode Owner auf Kundenseite

Codeanalyse. Salesforce Code Analyzer3 prüft Apex, Lightning-Komponenten und Flows auf bekannte Sicherheits- und Performanceprobleme. Von sich aus schreibt er nur einen Bericht. Ich würde ihn vom ersten Tag an ab Schwere High sperren lassen und alles darunter berichten. Alles zu sperren erzeugt in einer Org mit zehn Jahren Apex Hunderte alter Befunde, und Partner fangen an, Regeln abzuschalten, statt sie zu beheben.

Regeln für Agenten. Die Standardregeln kennen Ihre Org nicht. Zwei Ergänzungen lohnen sich bei KI-generiertem Code: eigene Regeln für Muster, die Sie nie wollen, etwa fest eingetragene Adressen, wo Ihre SAP-Schnittstelle eine hinterlegte Verbindung nutzen soll, und die Versionsprüfung aus dem Beispiel oben. Erwarten Sie von der Analyse kein Urteil über Testqualität: Ein Test mit einer nichtssagenden Prüfung besteht sie.

Testdeployment. Bevor etwas gemergt wird, spielt die Pipeline die Änderung probeweise in eine Integrations-Sandbox ein, eine Testkopie Ihrer Org mit allen Feldern, und führt alle eigenen Tests aus. Installiert wird dabei nichts; der Lauf zeigt nur, ob das Release funktionieren würde. Dort scheitern ein erfundenes Feld oder eine fehlende Abhängigkeit, bevor ein Mensch prüft. Für Produktion verlangt Salesforce 75 Prozent Testabdeckung und ausschließlich bestandene Tests (Apex Testing Best Practices4). Ein erfolgreicher Lauf lässt sich innerhalb von 10 Tagen ohne erneute Tests ausrollen (Befehlsreferenz5).

ApexGuru. ApexGuru findet langsame Muster wie Abfragen ohne Begrenzung. Laut Salesforce ist es „available only in Production and Full Copy Sandbox orgs“ und bewertet Befunde mit den Laufzeitdaten von dort (Salesforce Developers Blog6). Einer Pipeline gegen eine Integrations-Sandbox fehlen diese Daten womöglich, deshalb nutze ich ApexGuru als Bericht je Release.

Merge-Sperre. Prüfungen wirken nur, wenn eine rote Pipeline den Merge stoppt. Auf GitHub können Administratoren den Branch-Schutz umgehen, solange eine eigene Einstellung das nicht verbietet (GitHub Docs7). Haben Partner-Admins Zugriff auf das Repository, würde ich diese Einstellung einschalten und eine Person auf Kundenseite zum Code Owner für Sharing, Berechtigungen und Schnittstellencode machen.

Für Entwickler

Befehle und Einstellungen hinter den fünf Prüfungen

• Codeanalyse: sf code-analyzer run --severity-threshold 2 (2 ist High) oder die offizielle GitHub Action in Version 2; Version 1 nutzt noch den abgekündigten Code Analyzer v4 (CI/CD-Integration (öffnet in einem neuen Tab), Befehlsreferenz (öffnet in einem neuen Tab)).
• Eigene Regeln: Regex-Regeln in code-analyzer.yml mit Muster, Dateiendungen und Schwere (Regex-Engine (öffnet in einem neuen Tab)), etwa WITH SYSTEM_MODE ohne schriftliche Begründung. Die PMD-Regel ApexUnitTestClassShouldHaveAsserts prüft nur auf „at least one assertion“ (PMD Best Practices (öffnet in einem neuen Tab)).
• Versionsprüfung: apiVersion in geänderten -meta.xml-Dateien mit dem Ziel-Branch vergleichen und scheitern, wenn der Wechsel nicht beauftragt war. Ab 67.0 läuft Apex standardmäßig im User Mode (Apex Developer Guide (öffnet in einem neuen Tab)); ein Wechsel braucht einen Test mit System.runAs() und eingeschränktem Nutzer.
• Testdeployment: sf project deploy validate mit RunLocalTests, Release mit sf project deploy quick und der Job-ID. RunRelevantTests ist noch Beta.
• Merge-Sperre: Required Status Checks, Code Owners und „Do not allow bypassing the above settings“ am geschützten Branch.

sfdx-hardis deckt das meiste als Open Source ab

sfdx-hardis startet laut seiner Dokumentation zu den Pull-Request-Ergebnissen8 bei jedem Pull Request zwei Kontrolljobs. Der eine simuliert das Deployment in der Ziel-Org, führt die Tests aus, prüft die Abdeckung und schreibt das Ergebnis als Kommentar in den Pull Request. Der andere prüft die Codequalität und kommentiert seine Befunde ebenfalls. In der dokumentierten Konfiguration darf nur der Release Manager die Fehlerschwelle ändern, und Ausnahmen sind „only for false positives, never to publish faster“ gedacht (MegaLinter-Fehler9).

ApexGuru und org-spezifische Regeln wie die Versionsprüfung gehören nicht zu den dokumentierten Jobs; ergänzen Sie sie als eigene Schritte. sfdx-hardis führt außerdem eine automatische Korrektur durch einen Coding-Agenten für gescheiterte Deployments, noch als Beta (Übersicht10). Solche Korrekturen würde ich nur annehmen, wenn sie dieselben Prüfungen bestehen und ein Mensch sie prüft. Wie der Rest der Pipeline zusammenpasst, steht in Warum DevOps über Salesforce-Enterprise-Projekte entscheidet.

Schreiben Sie die Prüfungen in jeden Partnervertrag

Diese Prüfungen für Programme mit mehreren Partnern aufzusetzen, ist der Kern meiner Arbeit im DevOps- und Release-Management. Die Reihenfolge zählt, denn ein Partner kann jede Schwelle abschalten, solange die Pipeline ihm gehört.

1. Die Pipeline gehört Ihnen. Repository, Pipeline und Schwellen liegen bei Ihnen, wie in Warum Kunden ihre DevOps-Tools selbst besitzen sollten beschrieben.
2. Codeanalyse ab High sperren lassen und den vollständigen Bericht bei jedem Pull Request veröffentlichen.
3. Jeden Pull Request testweise deployen, in eine Integrations-Sandbox und mit allen eigenen Tests.
4. Ungefragte Versionswechsel stoppen und für jeden beauftragten Wechsel einen Test mit eingeschränktem Nutzer verlangen. Dieselbe Regel gehört in die KI-Regeldatei Ihres Repositorys, damit Agenten sie kennen, bevor die Pipeline sie stoppt.
5. Den Hauptzweig schützen, ohne Ausnahme für Admins und mit Code Owners auf Ihrer Seite für Sharing und Schnittstellen.
6. ApexGuru je Release laufen lassen, gegen eine Org, in der es Laufzeitdaten hat.
7. Gescheiterte Prüfungen je Partner und Kategorie zählen, jeden Monat. Eine steigende Kategorie zeigt, welche Regel in der Regeldatei oder im Vertrag fehlt.

Quellen10

1. 1DORA-Report 2025 (öffnet in einem neuen Tab)cloud.google.com
2. 2Salesforce Developers Blog (öffnet in einem neuen Tab)developer.salesforce.com
3. 3Salesforce Code Analyzer (öffnet in einem neuen Tab)developer.salesforce.com
4. 4Apex Testing Best Practices (öffnet in einem neuen Tab)developer.salesforce.com
5. 5Befehlsreferenz (öffnet in einem neuen Tab)developer.salesforce.com
6. 6Salesforce Developers Blog (öffnet in einem neuen Tab)developer.salesforce.com
7. 7GitHub Docs (öffnet in einem neuen Tab)docs.github.com
8. 8Dokumentation zu den Pull-Request-Ergebnissen (öffnet in einem neuen Tab)sfdx-hardis.cloudity.com
9. 9MegaLinter-Fehler (öffnet in einem neuen Tab)sfdx-hardis.cloudity.com
10. 10Übersicht (öffnet in einem neuen Tab)sfdx-hardis.cloudity.com