Operational Excellence – DevOps Patterns
Weitere Informationen zu Well-Architected Operational Excellence → DevOps Practices
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 |
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 |
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 |
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 |
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 |
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 |