Salesforce DX als moderne Entwicklungsmethode ist seit Jahren in aller Munde. Die Vorteile des sourcecode-zentrierten Ansatzes liegen auf der Hand. Teams können damit Features unabhängig voneinander entwickeln, testen und anschließend risikolos über die Versionskontrolle zusammenführen und releasen.

DX schafft so Prozessagilität, wie es sie davor auf der Plattform nicht gab. Das wissen auch unsere Kunden und erwarten von uns entsprechende Beratung. Für Neuentwicklungen nutzen wir ausschließlich DX. Bestehende Produkte unserer Kunden stellen wir schrittweise auf DX um. Wie der folgende Fall aus unserem Kundenumfeld zeigt, wissen aber noch wenige, dass DX auch außerhalb der Produktentwicklung große Vorteile bietet.

Salesforce DX Workflow

Salesforce DX – nicht nur für ISVs und Managed Packages

Ein Kunde, den wir seit Jahren mit mehreren Managed Packages auf AppExchange begleiten, ist selbst überzeugter Salesforce-Anwender. Seine Produktiv-Org deckt einen Großteil der Geschäftsprozesse ab – ob nun mit Salesforce Bordmitteln für CRM, Case- und Lizenzmanagement oder mithilfe eigener Anpassungen.

Über die Jahre haben interne Anwender und Entwickler zahlreiche Custom Objects, Klassen, Flows, Visualforce-Pages und Aura-Komponenten erstellt und damit Prozesse wie Recruiting, die Angebots- und Rechnungsstellung oder das Urlaubsmanagement abgebildet. Kleine Anpassungen nahmen Administratoren direkt in der Produktiv-Org vor. Für größere Erweiterungen wurden Developer Sandboxes genutzt, für Tests Full- oder Partial Copy Sandboxes. Die Metadatenänderungen wurden mit Change Sets zwischen den Orgs verschoben.

So einfach dieser Prozess klingt, so tückisch sind die Fallstricke bei seiner Anwendung. Ohne eine Versionskontrolle ist die Org das einzige führende System. Ein Undo bei Fehlern gibt es nicht. Mit Sandboxen enstehen alternative „Wahrheiten“, die mit der Produktiv-Org „konkurrieren“. So passen z. B. Business User das Produktsystem an, Entwickler aber die Kopie in der Sandbox. Wird später alles per Change Set deployed, können versehentlich Anpassungen überschrieben werden. Oder noch schlimmer: die Sandbox mit einem unfertigen Entwicklungsstand wird durch versehentliches Refresh überschrieben.

Problematische Abhängigkeiten zwischen Metadaten – die Happy Soup

Change Sets sind nicht das richtige Werkzeug um komplexe Metadaten-Änderungen zu konsolidieren. Mittlerweile gibt es gute kommerzielle Tools (wie z. B. Gearset) welche die Risiken von Change Sets minimieren. Ein Problem jedoch beseitigen auch diese nicht. Und das heißt in der Sprache von Salesforce DX– Happy Soup.

Struktur schaffen in kleinen Schritten

Über Jahre gewachsene und stark genutzte Salesforce-Orgs gleichen einem schmackhaften Eintopf aus Tausenden von Metadaten, die alle irgendwie, schwer nachvollziehbar, miteinander zusammenhängen. Was für den Anwender nach klar abgegrenzten Prozessen aussieht, ist auf der Ebene der Metadaten alles miteinander verwoben – über gemeinsam referenzierte Objekte, Felder, Trigger und Testklassen.

In diesem Setup hatte unser Kunde über Monate in einer Sandbox Anpassungen an der Rechnungsabwicklung vorgenommen und wollte diese vor dem Quartalswechsel per Change Set live stellen. Innerhalb von zwei Tagen. Das Deployment zog sich dann aber über 2 Wochen hin. Die versteckten Abhängigkeiten zwischen den Metadaten führten dazu, dass Change Sets sich zunächst gar nicht installieren ließen. Über Trial-and-Error Deployments musste zunächst rausgefunden werden, was wie zusammenhängt. Dabei wurden fälschlicherweise auch Metadaten in das Change Set mitaufgenommen, die für die Änderung gar nicht relevant waren. Beim Deployment wurden so neuere Metadaten in der Produktiv-Org mit veralteten Ständen aus der Sandbox überschrieben. Ein Rücksetzen war selbst dem Salesforce Support nicht mehr möglich.

DX Unlocked Packages als flexibles Ordnungstool

In der anschließenden Retrospektive wurde allen Beteiligten schnell klar, dass ein DX-Ansatz mit Versionskontrolle solche Probleme verhindert hätte. Allerdings wusste niemand, dass DX sich auch außerhalb der Welt von ISVs und Managed Packages nutzen lässt.

Da konnten wir aufklären: DX hat sogar ein eigenes Konzept für solche Fälle, die sogenannten Unlocked DX Packages. Unlocked Packages liegen auf dem Sweet Spot zwischen den upgradfähigen, aber unflexiblen Managed Packages und den flexiblen, aber nicht aktualisierbaren Unmanaged Packages. Sie sind „gemanaged“ also versionier- und installierbar, erlauben Upgrades und Deinstallationen und sind gleichzeitig flexibel änderbar – eben Unlocked. Damit sind sie genau das Richtige, um Org Customizations zu strukturieren.

Es dauerte weniger als eine Woche bis wir aus der Happy Soup des Kunden klar umrissene Unlocked Packages geschnürt hatten. Alle Packages haben ihr eigenes Git-Repository und können von nun an unabhängig weiterentwickelt und versioniert werden. Mit klaren Abhängigkeiten zwischen den Packages und jederzeit flexibel änderbar. Metadaten wurden so bereits nach ein paar Tagen von einem in ein anderes Package verschoben. Gemeinsam genutzte Objekte und Klassen führte man zu einem Basispackage zusammen. Dafür mussten in der Produktiv-Org keine früheren Package-Versionen deinstalliert werden.

Zusammenfassend lässt sich sagen: Ein Blick auf Salesforce DX lohnt sich nicht nur für ISV Partner, sondern für jede Firma die Salesforce in wichtigen Unternehmensbereichen einsetzt und regelmäßig um eigene Funktionen erweitert. Unlocked Packages sind genau das Mittel der Wahl um in kleinen, risikolosen Schritten ein komplexe Org in modulare Apps zu überführen.

Nächste Schritte

Sie benötigen weitere Details oder wollen Unlocked Packages direkt ausprobieren? Die weiterführenden Links helfen dabei: Ob nun der ausführliche Dreamforce-Vortrag zum Thema, die mehrteilige Blogreihe von Salesforce oder das praxisnahe Trailhead Modul.

Oder nehmen Sie Kontakt mit uns auf. Wir helfen gerne dabei Ihre Org nach Methoden moderner Softwareentwicklung zu strukturieren und für die agile Weiterentwicklung fit zu machen.