• >
  • Blog>
  • Salesforce DX – Die Developer Experience

Salesforce DX – Die Developer Experience

 Carmen Krämer /  14. Dezember 2017 /

Salesforce DX möchte den Arbeitsalltag von Salesforce Entwicklungsteams grundlegend verändern. Tatsächlich wird es als DAS neue Entwicklungsparadigma für die Salesforce Entwicklungs-Lifecycle angepriesen. Endlich können Teams effizient arbeiten!

Es ist also höchste Zeit Salesforce DX einmal auszuprobieren! Damit wir wissen, was wir tun, vorneweg die Theorie.

Zunächst die Trennung in „Paradigma“ und „Module/Tools“: Paradigma als den verbesserten Entwicklungs-Lifecycle (oder auch gesamten Application Lifecycle Management) und Module als die Tools, welche diesen ermöglichen sollen.

Das Paradigma

Bei der Salesforce Developer Experience (DX) geht es darum, den Entwicklungsprozess in Salesforce out-of-the-box an bereits gängigen modernen Software-Entwicklungsmethoden anzugleichen.

Bisher war beispielsweise ein Thema wie Versionierung so zeitaufwändig und komplex, dass sogar in der App-Entwicklung teilweise darauf verzichtet wurde oder die Lösung kaum mehr als ein besseres Backup war.

Salesforce DX verspricht jetzt vor allem ein „source-driven development“ (Erklärung kommt gleich) und das Vereinfachen der Zusammenarbeit im Team und damit mehr Agilität in der App-Entwicklung.

salesforce-dx.png

Source-Driven Development

Bisher sind wir alle das gewohnt, was von Salesforce jetzt als „org-based development“ bezeichnet wird: Die „Source“ ist die Produktionsumgebung, was für sie entwickelt wird, wird in Sandboxen umgesetzt (Developer Orgs lassen wir an dieser Stelle noch außen vor).

Mit Salesforce DX wird ein „artifact-based development“ eingeführt. Ein „Artifact“ ist hierbei eine logisch und funktional zusammenhängende Gruppe von Komponenten. Das können ein Flow mit 2 benutzerdefinierten Feldern, aber auch Pakete, wie z. B. unsere Solutions sein. Größere und/oder komplexere Anwendungen bestehen nach diesem Prinzip meist aus mehreren Artifacts.
Prinzipiell werden also alle Komponenten einer Produktionsumgebung in Module aufgesplittet.

„Source-driven development“ heißt außerdem, dass während der Entwicklung die Quelle für die Metadaten etc. („Source of Truth“) nicht die Produktionsumgebung ist, sondern ein Versionierungssystem, in dem die für dieses Artifact notwendigen Metadaten gespeichert sind.

Continuous Integration (CI) und Continuous Delivery (CD)

Wesentliche Bestandteile des Application Lifecycle Management und somit Teil des Paradigmas sind Continuous Integration (CI) und Continuous Delivery (CD) – man verzeihe mir an dieser Stelle die Anglizismen. Es gibt meiner Meinung nach keine gute Übersetzung für die Begriffe.

Die Artifacts werden also kontinuierlich wieder zusammengeführt, so dass sie eine App bilden (CI). Anschließend werden (automatisierte) Tests, UATs etc. durchgeführt, was regelmäßige, qualitativ hochwertige Aktualisierungen in der Produktionsumgebung (CD) ermöglichen soll.

Die Module/Tools

VCS - Version Control System

Das Version Control System (VCS) wird benötigt, um die Daten (Salesforce DX Projects) zu verwalten. Im Verzeichnis dieses Systems (Repository) wird die Historie des Codes und aller hochgeladenen und heruntergeladenen Veränderungen erfasst.

Mit Hilfe des VCS können Sie also überwachen, was erstellt, aktualisiert und gelöscht wurde.

Für alle, die noch kein Version Control System auf dem Laptop haben: Bei Installation des Salesforce CLI (siehe unten) wird ein lokales Git Repository angelegt.

Scratch Orgs

Scratch Orgs sind vergleichbar mit Developer Orgs. Sie ist zwar mit der Original Org (Dev Hub) verknüpft, verfügt aber beim Erstellen noch über keine dort gemachten Anpassungen.

scratchOrg.png

Es geht hier vor allem darum, eine Org zu haben, in die man sich nur die Anpassungen hochlädt (über Salesforce CLI, siehe unten), die Sie gerade zum Entwickeln brauchen. In einer Umgebung, die man schnell erstellen und auch wieder schnell löschen kann (die aber umgekehrt auch keine maximale Laufzeit hat).

Während Sie im DX Paradigma vor allem lokal programmierten und die Änderungen dann (über das Repository) in die Scratch Org hochladen, können Sie deklarative Aufgaben in der Scratch Org erledigen und sich dann die Daten von hier aus in das Repository ziehen.

Für eine gute Zusammenarbeit im Team sorgt die Konfigurationsdatei für die Scratch Org, die Sie mit allen Kollegen teilen können. Jeder hat auf diese Weise die gleiche Ausgangssituation.

Diese Konfigurationsdatei enthält Informationen zur erstellenden Org im JSON-Format und in ihrer Größe, abhängig von den Anforderungen. Es gibt nur ein Pflichtfeld (edition), die Datei kann aber detaillierte Informationen über zu aktivierende Funktionen enthalten.

cli.png

Salesforce Command Line Interface – CLI

Das lokal auf dem Laptop gespeicherte Command Line Interface wird dazu genutzt, den Lifecycle zu steuern. Das Salesforce CLI bietet u. a. Funktionalitäten von Metadata API, Packaging und Force.com Migration Tool.

Das heißt im Klartext: Mit der Console steuert man das Erstellen von Scratch Orgs und kann nahezu das gesamte Setup der Scratch Org konfigurieren. Alle Änderungen, die Sie lokal vorgenommen haben, werden über das CLI hochgeladen; Änderungen, die Sie in der Scratch Org erstellt haben, heruntergeladen. Auch Datensätze können Sie relativ einfach im JSON-Format in die Scratch Org hochladen.

Nach ersten Erfahrungen muss ich sagen, es ist wirklich einfach zu installieren. Hätte ich nicht erwartet. Und: funktioniert sogar auf Anhieb reibungslos in der Windows Konsole.

Brauche ich das?

Ob Sie mit Salesforce DX arbeiten oder nicht, ist von verschiedenen Faktoren abhängig. Arbeitet nur ein sehr kleines Team in einer Org, sind Sandboxen völlig ausreichend. In komplexeren Orgs sollten Sie auch bei einem kleinen Team abwägen, ob Sie DX aufsetzen. Grund hierfür wäre vor allem die Möglichkeit, schnell und eher unkompliziert zu früheren Versionen einer App zurückzugehen (Stichwort Versionierung), wenn dann beim „Go-Live“ oder an anderer Stelle doch etwas unerwarteter Weise schiefgeht. Kommt aber auch hier auf die Komponenten an.

whichEnvironment.png

Ein noch gar nicht angesprochenes Thema sind die Managed Packages, die meist als App auf AppExchange gelistet werden. Hier kann ich aus eigener Erfahrung sagen: wenn noch kein gut eingerichtetes end-to-end-lifecycle System besteht, haben Sie eigentlich keine Ausrede, DX nicht zu benutzen.  

So oder so gilt: Je größer und komplexer eine Org wird, desto wichtiger ist es, die angestammten Prozesse zu evaluieren und ggf. zu optimieren. Und hier bietet Salesforce DX tatsächlich großes Potential.

Haben Sie sich entschieden umzustellen, ist einiges an Planung nötig: existierende Komponenten müssen in Artifacts gebündelt werden, diverse Fragen gilt es abzuklären, wie beispielsweise welche Metadaten von mehreren potentiellen Artifacts benötigt werden etc. Wir unterstützen Sie gerne!

Resourcen


Haben Sie Fragen zu Salesforce DX oder anderen Salesforce.com Produkten? Unsere Salesforce Berater helfen Ihnen gern weiter!

Beratungstermin vereinbaren

 

Carmen Krämer

Autor: Carmen Krämer

Salesforce Developer bei der Cloud Consulting Group

Salesforce Produkte Salesforce Implementation Salesforce Development

Letzte Beiträge

Blog Themen

Alle ansehen

Schlagworte

Alle ansehen