---
schema_version: "1"
id: afc519214bfce21a0851bd261ec88256bb43b83853e8d6edeb0f7e13c0339e8a
title: Operational Excellence – DevOps Patterns
collection: architect
version: current
locale: de-de
portal_url: https://docs.salesforce.com/architect/current/de-de/well-architected/guides/operational-excellence-devops-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/de-de/well-architected/guide/operational-excellence-devops-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: f5ac4f9bdf2f39cf750f100cab529258b82e99e7a216a729f8c928a6f1936150
products:
  - Gut strukturiertes Framework
  - Architect Site Content Repo
---
# Operational Excellence – DevOps Patterns

<br>

Weitere Informationen zu Well-Architected [Operational Excellence](/docs/architect/de-de/well-architected/guide/operational-excellence.html) → [DevOps Practices](/docs/architect/de-de/well-architected/guide/operational-excellence.html#devops-practices)

## Quellgesteuerte Entwicklung

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Setup der Versionskontrolle    | ✅ Alle im Git-Quellformat gespeicherten Metadaten mit Salesforce DX-Projektstruktur, wobei .forceignore so konfiguriert ist, dass irrelevante Dateien ausgeschlossen werden. Alle Teammitglieder duplizieren aus dem zentralen Repository |
| Nutzung der Testorganisation        | ✅ Entwickler erstellen temporäre Testorganisationen aus der Quelle für Funktionsarbeiten, übernehmen Änderungen wieder an der Versionskontrolle und verwerfen Testorganisationen nach Abschluss der Funktion |
| Commit-Nachrichten          | ✅ Jeder Commit enthält eine klare, prägnante Nachricht, in der erläutert wird, was sich geändert hat und warum. Nachrichten folgen der Teamkonvention (z. B. "feat:", "fix:", "docs:") |
| Change Tracking (Änderungsverfolgung)          | ✅ Jede in der Versionskontrolle erfasste Metadatenänderung mit Autorenidentität, Zeitstempel und Unterschied, die genaue Änderungen anzeigen |
| Code-Überprüfungsprozess      | ✅ Alle produktionsgebundenen Änderungen durchlaufen Pull-Anforderungen, die vor dem Zusammenführen eine Genehmigung zur Überprüfung erfordern; die deklarative Konfiguration wird wie Code geprüft |
| Wiederherstellungsverfahren      | ✅ Frühere Versionen, die durch Checkout oder Rückgängigmachen aus dem Git-Verlauf wiederhergestellt werden können. Das Team hat dokumentierte Wiederherstellungsverfahren, die in der Nicht-Produktion getestet wurden |
| Audit Trail (Aktivierungsprotokoll)              | ✅ Vollständiger Änderungsverlauf, der in der Versionskontrolle beibehalten wird und Compliance-Anforderungen und Sicherheitsuntersuchungen unterstützt |
| Verzweigungsstrategie       | ✅ Konsistentes Git-Verzweigungsmodell (GitFlow, GitHub-Flow oder Trunk-basiert), das der Teamgröße und der Veröffentlichungshäufigkeit entspricht; dokumentiert und erzwungen |
| Migration von organisationsbasiert | ✅ Umstellung auf die quellgesteuerte Entwicklung früh im Lösungslebenszyklus abgeschlossen, bevor sich die Gewohnheiten in Bezug auf die organisationsbasierte Entwicklung verfestigen |
| .gitignore-Konfiguration | ✅ Das Repository schließt generierte Dateien, benutzerspezifische Einstellungen und Anmeldeinformationen aus. Enthält nur Quelldateien, die Teams versionieren möchten |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Organisation als Quelle der Wahrheit   | ⚠️ Die Entwicklung erfolgt direkt in freigegebenen Sandbox-Instanzen mit Metadaten, die nach Bedarf in die Versionskontrolle exportiert werden. Organisationen und Versionskontrolle weichen voneinander ab und führen zu Bereitstellungsfehlern |
| Unzureichende .gitignore    | ⚠️ Das Repository enthält generierte Dateien, benutzerspezifische Einstellungen, große Binärdateien oder Anmeldeinformationen. |
| Unklare Commit-Meldungen    | ⚠️ Comits wie "Fehler beheben" oder "Aktualisierungen" bieten keinen Kontext für das, was geändert wurde oder warum; behindert Überprüfungsuntersuchungen und zukünftige Wartung |
| Große seltene Komitees | ⚠️ Entwickler übernehmen mehrmals täglich große Änderungssets anstelle kleiner inkrementeller Übertragungen; schwer zu überprüfen, schwer zu isolierende Fehler |
| Direktes Commit an den Main  | ⚠️ Entwickler übertragen Änderungen direkt an die Haupt-/Produktionszweigstelle, um die Überprüfung und Validierung zu umgehen; beseitigt Qualitätstore |
| Keine Verzweigungsstrategie    | ⚠️ Team fehlt ein konsistentes Verzweigungsmodell; Entwickler erstellen beliebige Zweigstellennamen und Zusammenführungsmuster; führt zu Verwirrung und Zusammenführungskonflikten |
| Binärdateien in Git      | ⚠️ Große Binärdateien (PDFs, Videos, Archive), die an Git-Blähungen im Repository und langsamere Duplizierungsvorgänge gebunden sind |
| Commit-Anmeldeinformationen   | ⚠️ API-Schlüssel, Kennwörter, Integrationsanmeldeinformationen oder Sicherheitstoken, die für die Versionskontrolle übernommen wurden; schafft Sicherheitslücken auch nach der Entfernung aus späteren Commits |
| Ignorieren von Zusammenführungskonflikten | ⚠️ Konflikte beim Zusammenführen durch Akzeptieren einer Seite ohne Analyse gelöst; Änderungen gehen verloren oder Fehler treten auf |
| Keine Commit-Überprüfung   | ⚠️ Das Team überprüft nie, ob übernommene Metadaten tatsächlich die beabsichtigten Änderungen darstellen; Metadatenformatfehler oder unbeabsichtigte Änderungen rutschen durch |

## Sandbox-Strategie

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Developer Sandbox-Instanzen                | ✅ Einzelne Entwickler verwenden Developer Sandbox-Instanzen für Funktionsarbeiten, Einheitentests und schnelle Iteration. Jeder Entwickler verfügt über eine dedizierte Umgebung |
| Developer Pro-Sandbox-Instanzen            | ✅ Teams, die verwaltete Pakete entwickeln oder höhere Speicherobergrenzen erfordern, verwenden Developer Pro-Sandbox-Instanzen für die Zusammenarbeit |
| Teilkopie-Sandbox-Instanzen             | ✅ Integrationstests verwenden Teilkopie-Sandbox-Instanzen mit repräsentativen Datenbeispielen (10.000 Datensätze pro Objekt), die über Datenvorlagen konfiguriert sind |
| Full Copy Sandbox-Instanzen                | ✅ Leistungstests, produktionsähnliche Staging und Datenmigrationsvalidierung verwenden Full Copy-Sandbox-Instanzen mit vollständigen Produktionsdaten und Konfiguration |
| Steuerelemente für die Datenvertraulichkeit          | ✅ Vollständiger Kopierzugriff auf Sandbox-Rollen, für die Produktionsdaten erforderlich sind; Shield Platform Encryption-Datenmaskierung bei Nicht-Produktionsanwendung |
| Integrationsendpunktkonfiguration | ✅ Jede Sandbox-Stufe stellt eine Verbindung zu den entsprechenden Testendpunkten für externe Integrationen her. Produktionsintegrationen werden niemals über Sandbox-Integrationen verbunden |
| Umgebungsspezifische Konfiguration        | ✅ Die Integrationsarchitektur verwendet benutzerdefinierte Metadatentypen oder benutzerdefinierte Einstellungen zum Externalisieren von Endpunkt-URLs, Anmeldeinformationen und Funktionskennzeichnungen pro Umgebung |
| Automatisierung nach der Aktualisierung            | ✅ Sandbox-Aktualisierungen lösen automatisierte Salesforce CLI Skripts aus, die Sandbox-spezifische Einstellungen wie Integrationsanmeldeinformationen, Testdaten-Seeding, Funktionskennzeichnungsstatus und E-Mail-Zustellbarkeit wiederherstellen |
| Aktualisieren der Planung                 | ✅ Sandbox-Aktualisierungsplan dokumentiert und kommuniziert; Aktualisierungen in Zeiträumen mit geringer Aktivität geplant, um Teamunterbrechungen zu minimieren |
| Datenvorlagen                     | ✅ Teilkopie-Sandbox-Instanzen verwenden gut gestaltete Datenvorlagen, die repräsentative Daten über Objekte hinweg auswählen, wobei die referenzielle Integrität erhalten bleibt |
| Benennungskonventionen                 | ✅ Sandbox-Instanzen folgen der Konvention zur eindeutigen Benennung, die Zweck, Inhaber und Aktualisierungszyklus angibt (z. B. "dev-integration-q2", "uat-release-2-4") |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Gemeinsame Entwicklungs-Sandbox           | ⚠️ Alle Entwickler arbeiten in einer einzelnen freigegebenen Sandbox und überschreiben die Änderungen gegenseitig. |
| Stale Sandbox-Instanzen                      | ⚠️ Sandbox-Instanzen, die seit Monaten nicht aktualisiert wurden, weichen erheblich von der Produktionskonfiguration ab. Tests in einer nicht repräsentativen Umgebung führen zu Bereitstellungsfehlern |
| Keine Datenverwaltung in vollständiger Kopie      | ⚠️ Full Copy Sandbox-Instanzen mit personenbezogenen Daten der Produktion, Finanzdaten und HIPAA-Daten, auf die das gesamte Entwicklungsteam ohne Zugriffssteuerungen oder Datenmaskierung zugreifen kann |
| Produktionsintegrationen aus der Sandbox | ⚠️ Sandbox-Instanzen werden direkt mit Produktionsintegrationsendpunkten verbunden, wodurch das Risiko besteht, dass sich Testtransaktionen auf Produktionsdaten oder externe Systeme auswirken. |
| Manuelle Konfiguration nach der Aktualisierung    | ⚠️ Sandbox-Aktualisierungen erfordern stundenlange manuelle Einstellungen für die Wiederherstellung der Neukonfiguration. Darüber hinaus wird verhindert, dass Sandbox-Instanzen nach Bedarf aktualisiert werden |
| Keine Sandbox-Dokumentation             | ⚠️ Dem Team fehlt die Dokumentation zu Sandbox-Zwecken, Aktualisierungsplänen, Dateninhalten oder Zugriffsverfahren. Entwickler schätzen, welche Umgebung zu welchem Zweck verwendet werden soll |
| Einzelner Umgebungstyp              | ⚠️ Das Team verwendet nur einen Sandbox-Typ (in der Regel Developer oder Full Copy) für alle Zwecke. Die Vorteile der entsprechenden Sandbox-Strategie pro Aktivität fehlen |
| Sandbox-Hortung                     | ⚠️ Sandbox-Instanzen, die Einzelpersonen oder Projekten zugewiesen und nie veröffentlicht wurden, wenn sie nicht mehr benötigt werden; künstliche Verknappung trotz verfügbarer Lizenzen |
| Unzureichende Testdaten                 | ⚠️ Testdaten in Sandbox-Instanzen stellen keine Produktionsdateneigenschaften (Volumen, Beziehungen, Edge-Kundenvorgänge) dar. Bei Tests in unrealistischen Umgebungen werden Produktionsprobleme nicht berücksichtigt |

## CI/CD-Pipelines

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Quell-Commit-Phase         | ✅ Entwickler übernehmen Änderungen an Funktionsverzweigungen in Git mit klaren Commit-Meldungen, die Kontext und Gründe erläutern |
| Phase der statischen Analyse       | ✅ Salesforce Code Analyzer scannt Apex auf Sicherheitslücken (OWASP Top 10), Leistungs-Anti-Patterns (SOQL in Schleifen, DML in Schleifen), Code-Qualitätsprobleme (Komplexität, Duplikation) und Obergrenzenrisiken. |
| Einheitstestphase             | ✅ Apex-Tests führen die Einhaltung von Geschäftslogik und Obergrenzen in einer temporären Testorganisation oder einer speziellen Integrations-Sandbox aus; ordnungsgemäß isolierte Tests werden in weniger als 5 Minuten abgeschlossen |
| Validierungsbereitstellungsphase | ✅ Metadaten werden in der Integrations-Sandbox mithilfe der Salesforce CLI mit der Kennzeichnung --checkonly für die Ausführung von Tests für die reine Validierungsbereitstellung bereitgestellt, ohne Änderungen zu übernehmen |
| Integrationstestphase      | ✅ Automatisierte Tests validieren Mehrkomponenten-Workflows, externe Integrationsverträge, Plattformereignis-Flows und asynchrone Verarbeitungsketten mit gemeinsamer Integrationsumgebung und Testdatenverwaltung |
| Sicherheitsscanphase     | ✅ Zusätzliche Sicherheitstools scannen nach hartcodierten Anmeldeinformationen, verwundbaren Abhängigkeiten, CRUD/FLS-Verstößen und Verstößen gegen die Compliance-Richtlinien; kritische Befunde brechen Builds |
| UAT-Bereitstellungsphase        | ✅ Änderungen, die alle automatisierten Tore passieren, werden in der Benutzerakzeptanz-Testumgebung zur Geschäftsvalidierung bereitgestellt. Die Bereitstellung kann automatisiert sein oder eine manuelle Genehmigung erfordern, je nach Änderungsrisiko |
| Produktionsbereitstellungsphase | ✅ Nach der Genehmigung der Benutzeroberfläche werden Änderungen in der Produktion bereitgestellt, mit automatisierter Ausführung mit einem Klick, umfassender Protokollierung und sofortiger Rollback-Funktion |
| Ausführungszeit der Pipeline     | ✅ Durchgängige Pipeline in weniger als 15 Minuten für typische Änderungen, die schnelles Feedback ermöglichen; länger für große Bereitstellungen oder umfangreiche Test-Suites |
| Erstellen von Artefakten             | ✅ In der Pipeline werden Bereitstellungspakete, Testergebnisse, Sicherheitsscanberichte und Ausführungsprotokolle zur Einhaltung und Fehlerbehebung beibehalten |
| Pipeline-Tooling            | ✅ Teams verwenden das Salesforce DevOps Center für plattformeigene CI/CD oder integrieren es in externe Plattformen (GitHub-Aktionen, GitLab CI, Azure DevOps, CircleCI, Jenkins, Copado, Gearset, AutoRABIT) |
| Fehlerbenachrichtigungen       | ✅ Pipeline-Fehler lösen Benachrichtigungen aus, um Autor und relevante Kanäle mit Diagnosekontext zu verpflichten, der eine schnelle Behebung ermöglicht |
| Zweigstellenschutz           | ✅ Geschützte Haupt-/Produktionszweige, die CI-Prüfungen und genehmigte Überprüfungen vor der Zusammenführung erfordern; direkte Commits verhindert |
| Umweltförderung       | ✅ Änderungen durchlaufen definierten Sonderangebotspfad (Entwicklung → Integration → UAT → Produktion) mit Validierung in jeder Phase |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Manuelle Bereitstellungen          | ⚠️ Änderungen, die manuell über Änderungssets oder Salesforce CLI-Befehle mit inkonsistenten Schritten bereitgestellt werden; menschliche Fehler, verpasste Schritte, fehlender Prüfprotokoll |
| Keine statische Analyse          | ⚠️ Pipelines überspringen Salesforce Code Analyzer oder ähnliche Tools; Sicherheitslücken, Leistungseinbußen, Probleme mit der Codequalität erreichen die Produktion |
| Unzureichende Tests        | ⚠️ Die Pipeline validiert nur eine Abdeckung von mindestens 75 %, ohne Integrationstests auszuführen oder wichtige Benutzer-Flows zu validieren. |
| Kein Sicherheitsscan        | ⚠️ Pipelines werden niemals auf hartcodierte Anmeldeinformationen, anfällige Abhängigkeiten oder CRUD/FLS-Verstöße überprüft; Sicherheitsprobleme wurden bei Produktions- oder Sicherheitsüberprüfungen festgestellt |
| Langsame Pipeline-Ausführung     | ⚠️ Durchgängige Pipeline dauert 45-60+ Minuten, um häufige Commits zu verhindern und Feedbackschleifen zu verlangsamen. Entwickler übernehmen seltener größere Änderungen |
| Ignorierte Pipeline-Fehler   | ⚠️ Teams ignorieren oder überschreiben Pipeline-Fehler, um Fristen einzuhalten; Qualitätstore werden zum Theater und nicht zu tatsächlichen Kontrollen |
| Keine Testumgebungsparität  | ⚠️ CI/CD-Validierungen in Umgebungen mit anderen Konfigurations-, Obergrenzen- oder Dateneigenschaften als der Produktion; die bestandene Validierung garantiert nicht den Produktionserfolg |
| Fehlende Rollback-Funktion | ⚠️ Pipeline automatisiert die Bereitstellung, bietet jedoch keine automatische Wiederherstellung. Die Wiederherstellung nach fehlerhafter Bereitstellung erfordert manuelle Notfallverfahren |
| Keine Bereitstellungsprotokolle          | ⚠️ Bereitstellungen, die ohne umfassende Protokollierung ausgeführt werden; Fehlerbehebung oder Überprüfung von Bereitstellungen wird schwierig |
| Alles-oder-nichts-Testen      | ⚠️ Pipeline führt alle Tests für jede Änderung aus, unabhängig davon, was geändert wurde. 30-minütige Test-Suite wird auch für Dokumentationsaktualisierungen ausgeführt |

## Sichere Bereitstellungspraktiken

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Funktionskennzeichnungen                       | ✅ Bereitstellung von Änderungen mit hohem Risiko mit deaktivierten Funktionen hinter dem benutzerdefinierten Metadatentyp oder der Konfiguration benutzerdefinierter Einstellungen; ermöglicht Tests in der Produktion ohne Benutzerexposition, schrittweise Einführung in Segmente, A/B-Tests und sofortige Wiederherstellung über Konfigurationsänderungen |
| Funktionskennzeichnungsumfang                  | ✅ Funktionskennzeichnungen, die für Änderungen mit hohem Risiko reserviert sind, die sich auf wichtige Geschäftsprozesse, leistungskritische Vorgänge oder neue Integrationsmuster auswirken; nicht jede Funktion benötigt Kennzeichnungen |
| Kanarische Bereitstellungen                  | ✅ Veröffentlichung geschäftskritischer Änderungen an einer kleinen Benutzerteilmenge zuerst (5-10 % über Berechtigungssätze oder Benutzerattributfilterung); Kanarienvogel wird intensiv 24-48 Stunden überwacht und misst Erfolgsraten, Leistung und Fehlerraten, bevor die Einführung erweitert wird |
| Bereitstellungszeitfenster                  | ✅ Bereitstellungen, die in Zeiträumen mit geringer Nutzung geplant sind, die durch Ereignisüberwachungs-API-Nutzungsprotokolle informiert werden, die tatsächliche Datenverkehrsmuster anzeigen; Vermeidet Spitzennutzung, Monatsabschluss, Quartalsabschluss, wichtige Geschäftsereignisse |
| Bereitstellungskommunikation            | ✅ Beteiligte erhalten vorab eine Benachrichtigung über Bereitstellungszeitfenster, einschließlich der erwarteten Dauer, der betroffenen Funktionen und der Zeitachse für die Wiederherstellung der Entscheidung |
| Wiederherstellungsverfahren                 | ✅ Dokumentierte und getestete Rollback-Verfahren für jeden Bereitstellungstyp; das Team kann die Rollback-Vorgänge bei Bedarf in weniger als 30 Minuten ausführen |
| Rollback-Tests                    | ✅ Wiederherstellungsverfahren, die in Nicht-Produktionsumgebungen vor wichtigen Bereitstellungen validiert wurden, um sicherzustellen, dass Wiederherstellungsfunktionen vorhanden sind |
| Bereitstellungsvalidierung               | ✅ Rauchtests nach der Bereitstellung validieren wichtige Benutzer-Flows, Integrationsendpunkte und wichtige Funktionen direkt nach der Veröffentlichung |
| Koordination ändern                 | ✅ Koordinierte Bereitstellungsstrategie, wenn Änderungen mehrere Systeme umfassen oder synchronisierte Versionen über Salesforce und externe Plattformen hinweg erforderlich machen |
| Überwachung während der Bereitstellung        | ✅ Verbesserte Überwachung, die während des Bereitstellungsfensters und des Beobachtungszeitraums nach der Bereitstellung (24-48 Stunden) aktiv ist und auf Fehlerratenspitzen, Leistungseinbußen oder Benutzer-Flow-Fehler beobachtet |
| Blau-grünes Muster für Integrationen | ✅ Externe Services, die Salesforce vorantreiben, verwenden blaugrüne Bereitstellungen, die zwei produktionsähnliche Umgebungen beibehalten, wobei die Bereitstellung zuerst auf inaktiv festgelegt wird und der Datenverkehr nach der Validierung umgestellt wird |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Big Bang-Bereitstellungen            | ⚠️ Große Versionen, die viele Funktionen, Refaktoren und Änderungen enthalten, die gleichzeitig bereitgestellt werden, ohne dass eine schrittweise Einführung erfolgt; Fehler betrifft alle Benutzer sofort |
| Bereitstellungen zu Spitzenzeiten           | ⚠️ Geplante Versionen während der Hauptgeschäftszeiten (Mittag, Monatsende, Quartalsende), wenn die Nutzung am höchsten ist und die Auswirkungen von Problemen auf die Benutzer maximiert werden |
| Kein Wiederherstellungsplan                | ⚠️ Bereitstellungen erfolgen ohne dokumentierte und getestete Wiederherstellungsverfahren. Wenn Probleme auftreten, müht sich das Team, die Wiederherstellung herauszufinden |
| Funktionsumschalter nach Bedarf | ⚠️ Funktionskennzeichnungen werden reaktiv hinzugefügt, wenn Probleme auftreten, statt sie proaktiv für Änderungen mit hohem Risiko zu entwickeln. Beschränkt die Optionen für die Wiederherstellung auf die vollständige Wiederherstellung der Bereitstellung |
| Keine Bereitstellungsvalidierung        | ⚠️ Änderungen, die ohne Rauchtests nach der Bereitstellung in der Produktion bereitgestellt wurden; das Team geht davon aus, dass die Bereitstellung erfolgreich war, und fährt fort; Probleme, die Stunden später von Benutzern erkannt wurden |
| Nicht getestete Wiederherstellungsverfahren    | ⚠️ Wiederherstellungsverfahren dokumentiert, aber nie in der Nicht-Produktion getestet; während des tatsächlichen Vorfalls schlägt das Verfahren fehl oder erweist sich als unzureichend |
| Gleichzeitige Änderungen an mehreren Systemen | ⚠️ Koordinierte Änderungen zwischen Salesforce und externen Systemen, die ohne Synchronisierung oder Kompatibilitätstest bereitgestellt werden; erstellt Integrationsfehler |
| Keine Überwachungserweiterung       | ⚠️ Bereitstellungen erfolgen ohne erweiterte Überwachung während des Bereitstellungsfensters. Probleme werden durch Benutzerbeschwerden statt durch proaktive Benachrichtigungen erkannt |
| Wochenendbereitstellungen             | ⚠️ Bereitstellung von Hauptversionen am Freitag Abend oder an Wochenenden, wenn die Bereitschaftsabdeckung reduziert und die Verfügbarkeit des Anbietersupports begrenzt ist |

## Teststrategie

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Unit Test Coverage (Einheitentestabdeckung)           | ✅ Aussagekräftige Testabdeckung zur Validierung von Geschäftsregeln, Edge-Kundenvorgängen, Fehlerpfaden und dem Ansatz der Obergrenze; überschreitet die Mindestanforderung von 75 % deutlich |
| Unit Test Quality (Qualität des Einheitentests)            | ✅ Tests validieren die Geschäftslogik, nicht die Plattformfunktionalität; gut geschriebene Einheitentests sind schnell (Millisekunden), isoliert (kein freigegebener Status) und fokussiert (jeder Test validiert ein Verhalten) |
| Testdatenstrategie           | ✅ Tests verwenden @TestSetup-Methoden für allgemeine Testdaten. Vermeiden Sie SOQL-Abfragen in Tests nach Möglichkeit. Verwenden Sie Test.loadData() zum Laden statischer Ressourcen. |
| Externe Abhängigkeiten simulieren   | ✅ Einheitentests simulieren externe Callouts mithilfe von Test-Stubs und Abhängigkeitsinjektionen und ermöglichen eine schnelle Ausführung ohne tatsächliche HTTP-Anforderungen |
| Integrationstests            | ✅ Validieren von Interaktionen zwischen Auslösern, Flows, Plattformereignissen, Batchaufträgen und externen Callouts, die in Sandbox-Instanzen ausgeführt werden, mit repräsentativen Testdaten |
| Zuverlässigkeit von Integrationstests | ✅ Integrationstests sind wiederholbar und deterministisch. Sporadische Fehler werden durch Synchronisierungsmechanismen wie Plattformereignis-Wiedergabe-IDs und Batchauftragsabfragen behoben |
| Durchgängige Tests             | ✅ Automatisierte Browsertests (Selenium, Playwright, Provar) validieren vollständige Benutzer-Journeys für geschäftskritische Flows, die das System über die Benutzeroberfläche genau so ausführen, wie Benutzer interagieren |
| E2E-Testfokus               | ✅ E2E-Tests konzentrieren sich auf Benutzerpfade mit dem höchsten Wert aufgrund der langsameren Ausführung (Minuten pro Test) und des höheren Wartungsaufwands aufgrund von Benutzeroberflächenänderungen |
| Lasttests                 | ✅ Die Leistung wurde unter realistischen gleichzeitigen Benutzerlasten und Datenvolumen mit Salesforce Load Testing-Services oder Drittanbieter-Tools validiert. |
| Lasttesthäufigkeit          | ✅ Lasttests werden vor Hauptversionen und regelmäßig (vierteljährlich) ausgeführt, um die Leistung bei 3x-5x aktuellen Produktionsvolumen zu validieren |
| Testpyramide                 | ✅ Ausgewogene Testverteilung: viele Einheitentests (Hunderte, Minuten), weniger Integrationstests (Dutzende, Minuten), wenige E2E-Tests (unter 20, Minuten); schnelles Feedback an der Basis, umfassende Validierung oben |
| Testisolierung               | ✅ Tests hängen nicht voneinander ab; können in beliebiger Reihenfolge ausgeführt werden; jeder Test verlässt das System in einem sauberen Zustand oder verwendet @TestSetup für einen konsistenten Startpunkt |
| Negative Testfälle          | ✅ Tests validieren die Fehlerverarbeitung, die Erzwingung von Validierungsregeln, die Erzwingung von Berechtigungen und die ordnungsgemäße Verschlechterung unter widrigen Bedingungen |
| Governor Limit Testing (Obergrenze für Gouverneurstests)       | ✅ Tests validieren speziell das Verhalten, das sich den Obergrenzen nähert, einschließlich SOQL-Abfrageobergrenzen, DML-Obergrenzen, CPU-Zeit, Heap-Größe |
| Kontinuierliche Testausführung    | ✅ Tests werden automatisch bei jedem Commit über die CI/CD-Pipeline ausgeführt. Fehlschlagende Tests verhindern Bereitstellung in höheren Umgebungen |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Testen auf Abdeckung           | ⚠️ Tests, die nur geschrieben wurden, um eine Mindestabdeckung von 75 % zu erreichen, ohne Geschäftsregeln oder Edge-Kundenvorgänge zu validieren; Tests, die nichts behaupten oder triviale Codepfade testen |
| Testen der Plattformfunktionalität | ⚠️ Tests bestätigen, dass Salesforce Datensätze speichert oder SOQL-Abfragen funktionieren, statt Geschäftslogik zu validieren; verschwendet Aufwand für Plattformgarantien |
| Keine simulierte Strategie               | ⚠️ Einheitentests führen tatsächliche Callouts an externe Systeme aus. Tests sind langsam, brüchig für die Verfügbarkeit externer Systeme und verbrauchen API-Obergrenzen. |
| Sporadische Testfehler         | ⚠️ Tests bestehen oder schlagen unvorhersehbar fehl, basierend auf Ausführungszeit, Datenstatus oder Testausführungsreihenfolge. Teams lernen, Fehler zu ignorieren und erneut auszuführen, bis die Tests bestanden sind |
| Keine Integrationstests         | ⚠️ Es sind nur Einheitentests vorhanden. Das Team überprüft nie, ob Auslöser, Flows, Plattformereignisse und Batchaufträge ordnungsgemäß zusammenarbeiten. |
| Nur manuelle E2E-Tests        | ⚠️ Wichtige Benutzer-Flows, die vor jeder Version manuell validiert wurden; keine automatisierten E2E-Tests; Regressionen in der Produktion erkannt, wenn bei manuellen Tests Szenarien übersehen werden |
| Tests ohne Last                | ⚠️ Die Leistung wurde nie unter realistischen gleichzeitigen Lasten validiert; Probleme mit der Obergrenze, Sperrkonflikte oder Leistungseinbußen in der Produktion |
| Testen von Datenabhängigkeiten         | ⚠️ Tests hängen von bestimmten in der Organisation vorhandenen Datensätzen ab oder nehmen eine bestimmte Benutzerkonfiguration an. Pause bei Aktualisierung der Sandbox oder Konfigurationsänderungen |
| Keine negativen Testfälle         | ⚠️ Tests validieren nur Szenarien des glücklichen Pfads; testen Sie niemals die Fehlerverarbeitung, die Validierungserzwingung oder Berechtigungsprüfungen; Fehlermodi unentdeckt |
| Übersprungene Tests                  | ⚠️ Fehlerhafte Tests, die aus @isTest herauskommentiert und übersprungen statt behoben wurden; Test-Suite wird mit der Zeit schlechter, da mehr Tests ignoriert werden |

## Codeüberprüfung

**Muster**

| Wohin schauen | Wie gut aussieht |
| --- | --- |
| Abdeckung überprüfen                   | ✅ Alle produktionsgebundenen Änderungen durchlaufen die Codeüberprüfung über Pull-Anforderungen, die vor dem Zusammenführen genehmigt werden müssen. Dazu zählen Apex, Aura, LWC, Flows, Validierungsregeln, Berechtigungssätze, Freigaberegeln |
| Checkliste 'Kriterien überprüfen'         | ✅ Explizite Checkliste für Sicherheit (CRUD/FLS-Erzwingung, Eingabevalidierung), Leistung (Massenverarbeitung, SOQL-Optimierung), Einhaltung der Obergrenzen (Verarbeitungsmuster, Rekursionsvermeidung), Wartbarkeit (Benennung, Dokumentation, Komplexität), Testabdeckung (sinnvolle Tests, Randfälle), architektonische Konsistenz (Entwurfsmuster, Trennung von Bedenken) |
| Überprüfen von Größenbeschränkungen                | ✅ Pull-Anforderungen mit weniger als 400 Zeilen aussagekräftiger Änderungen ermöglichen eine gründliche Überprüfung; große Funktionen sind in kleinere inkrementelle Änderungen unterteilt, die einzeln überprüft und unabhängig bereitgestellt werden können |
| Überprüfen der Zeiteinteilung                     | ✅ Überprüfungen, die innerhalb eines Werktages abgeschlossen wurden, um die Entwicklungsdynamik aufrechtzuerhalten und schnelles Feedback zu geben; verzögerte Überprüfungen führen zu einem Wechsel des Kontext-Overheads |
| Automatisierte Vorabüberprüfungen       | ✅ Statische Analysen, Einheitentests und Sicherheitsscans werden automatisch ausgeführt, bevor eine menschliche Überprüfung angefordert wird. Automatisierte Überprüfungen erkennen mechanische Probleme, sodass sich Überprüfer auf Design und Geschäftslogik konzentrieren |
| Verteilte Überprüfungsverantwortung | ✅ Die Verantwortung für die Codeüberprüfung verteilt sich auf das gesamte Team, um Engpässe zu vermeiden und Knowledge freizugeben. Junior-Entwickler überprüfen älteren Code und erklären ihren eigenen Code während der Überprüfungen |
| Kommentarqualität überprüfen           | ✅ Überprüfer geben spezifisches, handlungsrelevantes Feedback mit Begründung; unterscheiden zwischen erforderlichen Änderungen (Blockierungsprobleme) und Vorschlägen (nice-to-have Verbesserungen) |
| Dokumentation überprüfen              | ✅ In den Beschreibungen der Pull-Anforderung wird erläutert, was sich geändert hat, warum sie geändert wurde, welche Tests durchgeführt wurden und welche speziellen Bereitstellungsüberlegungen oder Rollback-Verfahren gelten. |
| Überprüfung der deklarativen Konfiguration         | ✅ Flows, Validierungsregeln und Berechtigungsänderungen erhalten dieselbe Überprüfungsstrenge wie Code; die Konfiguration ist architektonisch und sollte überprüft werden |
| Folgemaßnahmen zu Kommentaren             | ✅ Alle Überprüfungskommentare, die vor dem Zusammenführen adressiert wurden; beantwortete Fragen, implementierte Änderungen oder Gründe, warum Vorschläge nicht übernommen wurden |

**Antimuster**

| Wohin schauen | Wie schlecht sieht |
| --- | --- |
| Keine Codeüberprüfung             | ⚠️ Änderungen, die direkt in die Produktionszweigstelle übernommen werden, ohne dass eine Überprüfung durch gleichrangige Personen erfolgt; beseitigt den Mechanismus zur Erkennung primärer Mängel |
| Gummistempeln            | ⚠️ Überprüfer genehmigen Pull-Anforderungen innerhalb von Sekunden, ohne Änderungen tatsächlich zu prüfen. Überprüfung wird zu Kontrollkästchen-Compliance statt zu Qualitätskontrolle |
| Single Reviewer Engpass | ⚠️ Nur ein leitender Entwickler ist zur Überprüfung des Codes autorisiert; führt zu Engpässen und einzelnen Fehlerpunkten; Knowledge konzentriert statt verteilt |
| Massive Pull-Anforderungen      | ⚠️ Abrufanforderungen, die Tausende von Änderungszeilen für mehrere Funktionen enthalten; eine gründliche Überprüfung ist nicht möglich, was zu einer oberflächlichen Überprüfung führt |
| Verzögerte Überprüfungen            | ⚠️ Pull-Anforderungen werden tage- oder wochenlang nicht überprüft; Entwickler verlieren den Kontext und wechseln zu anderen Aufgaben; Überprüfungskommentare werden angezeigt, wenn der Entwickler den mentalen Kontext gewechselt hat |
| Keine Überprüfungskriterien         | ⚠️ Das Team hat keine expliziten Kriterien dafür, was die Überprüfer untersuchen sollten; die Qualität der Überprüfung variiert stark je nach Überprüfer; einige Überprüfer konzentrieren sich auf den Stil, andere auf Logik, keine umfassenden |
| Überprüfen ohne Testen     | ⚠️ Überprüfer genehmigen Änderungen nur anhand der Code-Untersuchung, ohne Verzweigungen abzurufen und lokal zu testen oder automatisierte Tests zu validieren |
| Ignorierte automatische Überprüfungen   | ⚠️ Überprüfer genehmigen Pull-Anforderungen trotz fehlgeschlagener statischer Analysen, Sicherheitsscans oder Einheitentests; untergräbt Zweck automatisierter Qualitätstore |
| Feindseligkeitsüberprüfungskultur     | ⚠️ Überprüfungen werden zu persönlicher Kritik oder Wettbewerbsübung und nicht zu gemeinschaftlicher Qualitätsverbesserung, was Lernen und psychologische Sicherheit beeinträchtigt |
| Keine deklarative Überprüfung      | ⚠️ Flows, Validierungsregeln, Berechtigungssätze und Freigaberegeln werden ohne Überprüfung bereitgestellt, während Apex Code überprüft wird; führt zu einer Qualitätslücke bei der deklarativen Konfiguration |