Bewährte Verfahren für die Salesforce-Bereitstellung, wichtige Schritte & nützliche Tools

Salesforce bietet verschiedene Arten von Sandboxes mit unterschiedlichen Daten- und Dateispeicherkapazitäten, Aktualisierungsintervallen und Vorlagenunterstützung. Außerdem können nicht alle Sandboxes sowohl Metadaten als auch Daten kopieren. In einer Sandbox-Strategie sollte auf der Grundlage von Aufgaben und Datenanforderungen geklärt werden, welche Arten von Sandboxes in den einzelnen Release-Phasen beteiligt sind.

• Developer-Sandboxes kopieren die Metadaten Ihrer Produktionsorganisation, aber nicht die Daten. Sie können einmal pro Tag aktualisiert werden und haben im Vergleich zu anderen Typen eine begrenzte Speicherkapazität von 200 MB, was sie zu einer guten Wahl für einzelne Entwickler macht, die isolierte Codierungs- und Unit-Test-Aufgaben erledigen. Die Pro-Version erweitert die Speicherkapazität auf bis zu 1 GB und ermöglicht damit eine breitere Palette von Aufgaben wie Qualitätskontrolle und Integrationstests.

• Teilkopie-Sandboxes kopieren sowohl Metadaten als auch einen Teil der über Sandbox-Vorlagen ausgewählten Daten. Dieser Beispielsatz von Live-Daten ermöglicht es Ihnen, Änderungen über Integrationstests, Qualitätssicherung und UAT zu testen und Benutzer in einer Umgebung zu schulen, die der realen Umgebung ähnelt.
• Bei der Full Sandbox werden die Metadaten und Daten der gesamten Produktionsorganisation kopiert. Sie sollten daher zum Testen neuer Änderungen mit Performance-, Last- und UAT-Tests sowie als Staging-Umgebung verwendet werden. Beachten Sie, dass die niedrige Aktualisierungsrate trotz der besten Speicherkapazität den Entwicklungs- und Bereitstellungsablauf behindern kann, wenn sie als Codierungsumgebung verwendet wird.

Beim Festlegen Ihrer Sandbox-Strategie sollten Sie auch die Anzahl der verwendeten Sandboxes, ihre Verfügbarkeit auf der Grundlage der einzelnen Salesforce-Editionen und alternative Optionen zur Einrichtung neuer Sandboxes berücksichtigen.

• Mehrere Entwickler können sich dieselbe oder verschiedene Sandboxes teilen. Eine gemeinsame Sandbox macht Integration überflüssig, aber wir empfehlen dennoch, mehrere Sandboxes zu verwenden, damit jeder Entwickler Metadaten ändern kann, ohne die Arbeit der anderen Entwickler zu beeinträchtigen. Stellen Sie einfach sicher, dass Sie die Kompatibilität von Komponenten, die in verschiedenen Sandboxes erstellt wurden, durch Integrationstests überprüfen.

• Die verschiedenen Salesforce-Editionen bieten eine unterschiedliche Anzahl und Auswahl an Sandboxes, sodass Sie eine geeignete Auswahl treffen müssen. Sie können zwar zusätzliche Sandboxes erwerben, bedenken Sie jedoch, dass sich deren Kosten nach dem Typ richten, wobei die vollständige Sandbox am teuersten ist.
• Verwenden Sie die Salesforce CLI, um vorhandene Entwickler-Sandboxes zu klonen, anstatt neue Sandboxes aus der Produktionsorganisation zu erstellen, was länger dauert. So können Sie die Sandbox mit Daten vorladen, ohne Skripte zu verwenden.

Salesforce bietet mehrere native Optionen für die Bereitstellung von Änderungen zwischen verschiedenen Organisationseinheiten in Ihrer Release-Pipeline. Um das am besten geeignete Tool zu finden, sollten Sie Ihre Wahl anhand Ihres Bereitstellungsszenarios treffen.

• Änderungssets sind Pakete mit Metadatenänderungen (einschließlich Workflows, Regeln und Berechtigungssätzen), die direkt über das Setup-Menü der grafischen Benutzeroberfläche von Salesforce ausgewählt und bereitgestellt werden können. Dieses Tool unterstützt jedoch keine Versionskontrolle, was zu Fehlern und Schwierigkeiten bei der Änderungsverfolgung führen kann. Betrachten Sie Änderungssets als eine gute Option für technisch nicht versierte Benutzer, um kleinere Änderungen ohne Unterstützung durch Entwickler bereitzustellen.

• Das Ant Migration Tool (ehemals Force.com Migration Tool) ermöglicht Benutzern den Zugriff auf die Metadaten-API von Salesforce, um Metadaten zwischen Organisationen zu verschieben. Alle Interaktionen mit Ant, z. B. die Anforderung zur Bereitstellung von Salesforce-Metadaten, erfolgen durch die Eingabe von Textzeilen in eine Befehlszeilenschnittstelle. Obwohl der Prozess komplizierter ist als bei den grafischen Benutzeroberflächen, erhalten Sie eine größere Kontrolle über die Bereitstellung. Wählen Sie dieses Tool für umfangreiche Anpassungen, die wiederholte Bereitstellungen erfordern und von einem Team von Entwicklern durchgeführt werden sollen.
• Bitte beachten Sie, dass Salesforce die Unterstützung von Ant mit neuen Updates ab Frühjahr '24 einstellen wird, wie vor kurzem bekannt gegeben wurde. Wenn Sie sich für ein Befehlszeilen-Tool entscheiden, können Sie Ant durch Salesforce CLI ersetzen, das die Fähigkeiten von Ant um Befehle zum Ziehen und Ablegen von Metadaten in und aus Organisationen und zum Konvertieren von Metadaten in das SFDX-Format erweitert.

Tests sind notwendig, um eine erfolgreiche Salesforce-Bereitstellung, eine optimale Softwareleistung und einen reibungslosen Betrieb sowie eine nahtlose Benutzererfahrung sicherzustellen.

• Sie können mit dem Apex-Testing-Framework Unit-Tests schreiben und ausführen, um die hohe Qualität des Apex-Codes sicherzustellen und alle Anforderungen für die Bereitstellung zu erfüllen.
• Überprüfen Sie, ob die Codeabdeckung mindestens 75 % beträgt und ob Apex-Klassen (Vorlagen zum Erstellen von Objekten) und Trigger (Aktionen, die automatisch durch Änderungen an Salesforce-Datensätzen aufgerufen werden) wie erwartet funktionieren.

• Führen Sie Regressionstests durch, um sicherzustellen, dass sich Konfigurationsaktualisierungen oder neue Bereitstellungen nicht negativ auf die bestehende Funktionalität ausgewirkt haben. Erwägen Sie außerdem den Einsatz eines Automatisierungstools eines Drittanbieters, um solche Tests ohne manuelle Eingriffe auszulösen.
• Aktualisieren Sie Ihre Sandboxes regelmäßig, um sie mit der Produktionsumgebung zu synchronisieren und um Daten-/Metadatenabweichungen zwischen den Umgebungen zu vermeiden, die nach der Bereitstellung zu Fehlern führen könnten. Darüber hinaus geben Tests, die in synchronisierten Umgebungen durchgeführt werden, einen realistischeren Eindruck davon, wie Anpassungen in der Produktionsumgebung funktionieren werden.

Die Code-Versionskontrolle umfasst die Nachverfolgung und Dokumentation von Änderungen in jeder Phase der Entwicklung und Bereitstellung von Salesforce, die Pflege einer detaillierten Änderungshistorie und die Hervorhebung von Codekonflikten oder anderen Problemen zur Erleichterung der Fehlerbehebung.

• Das Setup Audit Trail von Salesforce zeigt die letzten Setup-Änderungen (Anpassungen des Seitenlayouts, erstellte Berechtigungssätze usw.), die in Ihrer Organisation vorgenommen wurden, einschließlich des Datums der Änderung und der Person, die sie vorgenommen hat.

• Entwickler sollten Konfliktbereiche zwischen den Komponenten des lokalen Projekts oder in der Organisation identifizieren (z. B. eine von einem Entwickler geänderte und von einem anderen gelöschte Datei) und diese lösen, bevor sie mit der Bereitstellung fortfahren. Sie können die Salesforce-Befehlszeilenschnittstelle (CLI) einsetzen, um Sie über widersprüchliche Änderungen zu informieren, damit Sie diese auflösen und das lokale Projekt oder die Organisation mit der aufgelösten Datei überschreiben können.
• Da viele Salesforce-Entwicklungsteams der Ansicht sind, dass die Versionskontrollfunktionen von Salesforce recht begrenzt sind, entscheiden sie sich häufig für ein Versionskontrollsystem eines Drittanbieters. Das beliebteste Versionskontrollsystem für Salesforce ist derzeit Git, mit dem Entwickler alle Branches (Arbeitslinien) und Commits (gespeicherte Punkte in der Historie) überwachen und Konflikte lösen können.

Aktive Zustellbarkeitseinstellungen und Validierungsregeln, übermäßig lockere Bereitstellungsrichtlinien und fehlende Rollback-Funktionen sind Schlüsselfaktoren, die sich negativ auf den Bereitstellungsprozess auswirken können und daher mit der nötigen Sorgfalt behandelt werden sollten.

• Wenn neue Metadaten in der Produktion bereitgestellt werden, müssen Sie möglicherweise zusätzliche manuelle Aufgaben durchführen, z. B. benutzerdefinierte Metadaten aktualisieren, Apex-Skripte zum Ändern von Daten ausführen und Änderungen in der Produktionsumgebung testen. Um reibungslose Prozesse nach der Bereitstellung zu gewährleisten, ohne Live-Daten zu beeinträchtigen oder Kunden mit unnötigen Benachrichtigungen zu belästigen, sollten Sie die Deaktivierung von E-Mail-Zustellbarkeitseinstellungen, bestimmten Validierungsregeln oder anderen Konfigurationen in Betracht ziehen, die Ihre Schritte nach der Bereitstellung beeinträchtigen könnten.

• Administratoren sollten die Anzahl der Benutzer, die über Berechtigungen zur Bereitstellung verfügen, begrenzen, um die Exposition der Organisation und das Risiko versehentlicher Änderungen zu minimieren. Zu den Berechtigungen, die besondere Aufmerksamkeit erfordern, gehören die Profilberechtigung "Anwendung anpassen" (die die Änderung einer Organisation erlaubt) und die Berechtigung "Metadaten-API-Funktionen" (die den Zugriff auf Metadaten über die API erlaubt).
• Salesforce-Organisationen speichern keine früheren Zustände und zugehörigen Metadaten, was bedeutet, dass von Ihnen bereitgestellte Änderungen nicht rückgängig gemacht werden können. Um zu einer früheren Konfiguration zurückzukehren und den Verlust von Daten und Metadaten zu verhindern, sollten Sie eine Sicherungs- und Wiederherstellungsstrategie anwenden. Dazu gehört, dass Sie sicherstellen, dass alle in einer Organisation bereitgestellten Änderungen in Ihrem Versionskontrollsystem vorhanden sind, sodass Sie zu Ihrem letzten Commit zurückkehren und die vorherige Version des Codes bereitstellen können. Sie können auch zusätzliche Kopien Ihrer Produktionsorganisation erstellen, wenn sich die Bereitstellung auf die Daten auswirkt (z. B. durch das Entfernen benutzerdefinierter Felder oder das Ändern von Feldtypen).

Durch die Anwendung bewährter CI/CD-Verfahren bei der Salesforce-Bereitstellung können Sie kleine Änderungspakete häufiger testen, integrieren und bereitstellen.

• Richten Sie eine CI/CD-Pipeline ein, um neue Änderungen bereitzustellen, sobald sie entwickelt und getestet sind, anstatt sie alle auf einmal zu veröffentlichen. Dies hilft den Entwicklern, Bugs und Abhängigkeitsprobleme zu minimieren, d. h. Änderungen an einer Systemkomponente, die sich auf andere Teile auswirken.
• Mit Salesforce Developer Experience, einer Reihe von Tools, die die Entwicklung auf der Salesforce-Plattform erleichtern, können Sie den CI/CD-Prozess mithilfe von Scratch-Organisationen rationalisieren. Dabei handelt es sich um kurzlebige Einwegumgebungen, die nach einer gewissen Zeit automatisch gelöscht werden. Scratch-Organisationen ermöglichen die schnelle Bereitstellung von Salesforce-Code und Metadaten zum Testen und Integrieren kleiner Änderungspakete.

• Entwickler müssen sicherstellen, dass Codeänderungen, die sie regelmäßig in ein Quellcode-Repository integrieren, keine Bugs enthalten. Sie können integrierte CI/CD-Tools von Drittanbietern wie CircleCI, Jenkins und Travis CI verwenden, um neue Änderungen automatisch zu testen, die Codeabdeckung zu überprüfen und solche Änderungen in einer Zielumgebung bereitzustellen.