Source-Driven Development in Salesforce, Erklärt

Source-Driven Development in Salesforce bedeutet, dass Ihr Git-Repository, nicht die Org, die einzige Source of Truth ist. Jede Änderung existiert als versionierte Datei, jedes Deployment lässt sich auf einen Commit zurückführen, und Ihre Pipeline baut Umgebungen aus dieser Quelle neu auf, statt Metadaten von Hand zwischen Orgs zu klicken. Es ist das Modell, um das herum Salesforce DX gebaut wurde, und 2026 ist es die Standardannahme hinter fast jedem ernsthaften Release-Prozess.

Was ist Source-Driven Development in Salesforce?

Im klassischen Ansatz gilt die Org als Source of Truth. Sie machen Änderungen in einer Sandbox, bündeln sie in ein Change Set und schieben sie weiter, in der Hoffnung, dass unterwegs nichts abdriftet. Source-Driven Development dreht das um. Ihre Metadaten leben als Dateien in der Versionsverwaltung, und die Org wird zu einer Abbildung dessen, was das Repository vorgibt. Wie Salesforces eigene DX-Doku festhält, beobachtet Source Tracking, was Sie erstellen, ändern oder löschen, damit Repository und Org ehrlich zueinander bleiben.

Der Gewinn ist Nachvollziehbarkeit. Jede Produktionsänderung verweist auf einen bestimmten Commit, das Code Review passiert vor dem Merge, und Sie erhalten kostenlos einen vollständigen Audit-Trail. Diese Governance ist in einer regulierten Salesforce-Org kein Nice-to-have; sie ist der Grund, warum sich Source-Driven Development durchgesetzt hat.

Worin unterscheidet es sich vom Org Development Model?

Salesforce liefert zwei Entwicklungsmodelle, und der Unterschied dreht sich im Kern um Source Tracking:

• Org Development Model: Sie arbeiten gegen Orgs, die keine Quelle verfolgen, etwa Produktion, Developer-Edition-Orgs oder nicht verfolgte Sandboxes. Sie geben von Hand an, was Sie abrufen und deployen.
• Source-Driven- (Package-) Modell: Sie arbeiten gegen source-verfolgte Orgs, vor allem Scratch Orgs und source-verfolgte Sandboxes. Salesforce DX verfolgt Änderungen auf beiden Seiten automatisch, und sf project deploy start oder sf project retrieve start bewegen nur, was sich wirklich geändert hat.

Die meisten Teams leben irgendwo dazwischen. Das ist in Ordnung. Die Richtung geht aber zu Source Tracking und weg von manuellen Change Sets, dieselbe Verschiebung, die wir in warum jedes Salesforce-DevOps-Tool Package Development ignoriert aufdröseln.

Warum hat das Source Format alles verändert?

Source-Driven Development funktioniert nur dank Source Format. Das alte Metadata Format packt ein ganzes Custom Object, seine Felder, Validierungsregeln und List Views in eine lange XML-Datei. Source Format zerlegt das in kleine, modulare Dateien, eine pro Komponente, unter einer hierarchischen Ordnerstruktur. Das Ergebnis, wie Gearset dokumentiert, sind sauberere Diffs und weit weniger Merge-Konflikte: Zwei Entwickler, die verschiedene Felder desselben Objekts bearbeiten, kollidieren nicht mehr, weil ihre Änderungen in getrennten Dateien liegen. Source Format ist inzwischen Salesforces empfohlener Standard für neue Projekte.

Wo tut Source-Driven Development noch weh?

Das ist der Teil, den die meisten Erklärungen überspringen. Source Format zerlegt nicht alles. Profiles, Permission Sets, Sharing Rules, Workflows und External Services landen weiterhin in großen, gemeinsam genutzten Dateien, sodass zwei Personen, die dasselbe Profile bearbeiten, in der Versionsverwaltung immer noch aneinandergeraten. Source Tracking deckt außerdem nicht jeden Metadatentyp ab; Sie müssen den Metadata Coverage Report prüfen, um zu wissen, was tatsächlich verfolgt wird, und genau diese Lücken verbrennen Teams.

Scratch Orgs machen das theoretisch sauberer, aber echte Orgs tragen Jahre an Konfiguration, die nie in Git gelebt hat. Der Weg zu Source-Driven ist eine Migration, kein Schalter, den man umlegt, und die Kosten, diesen Schritt nicht zu gehen, tauchen bei jedem Release auf, genau die Rechnung, die wir in den wahren Kosten manueller Salesforce-Deployments aufmachen. Werkzeuge, die diese unordentlichen Kanten versöhnen sollen, statt ein Greenfield-Projekt anzunehmen, trennen eine funktionierende Pipeline von einer Demo.

Wie führt man Source-Driven Development konkret ein?

1. Bringen Sie Ihre Metadaten in Git im Source Format. Abrufen aus der bestehenden Org, in Source Format konvertieren und committen. Das ist Ihre neue Baseline.
2. Wählen Sie ein Branching-Modell, das zu Ihren Orgs passt, damit jede Umgebung aus einem Branch baubar ist.
3. Aktivieren Sie Source Tracking, wo es geht, mit source-verfolgten Sandboxes und Scratch Orgs für Feature-Arbeit.
4. Automatisieren Sie Deployments aus Commits, damit nichts die Produktion erreicht außer über eine geprüfte, versionierte Änderung.
5. Planen Sie vorab für die nicht zerlegten Typen, indem Sie entscheiden, wem Profiles und Permission Sets gehören, bevor sie Konflikte verursachen.

Eine Pipeline, die Git als Source of Truth behandelt, Änderungen genau verfolgt und die Metadaten bewältigt, die Salesforce nicht vollständig zerlegt, ist genau das, wofür Serpent gebaut wurde. Der Open-Source-Stack kann Sie ebenfalls dorthin bringen, und wir geben ihm eine ehrliche Einschätzung in unserem Blick auf sfdx-hardis.

FAQ

Ist Source-Driven Development dasselbe wie Salesforce DX?

Nein. Salesforce DX ist das Werkzeug und das Format; Source-Driven Development ist die Praxis, Ihr Git-Repository statt der Org zur Source of Truth zu machen.

Brauche ich Scratch Orgs für Source-Driven Development?

Nein. Scratch Orgs helfen, aber auch source-verfolgte Sandboxes unterstützen Source Tracking, sodass Sie das Modell ohne einen vollständigen Scratch-Org-Workflow einführen können.

Beseitigt Source Format Merge-Konflikte?

Es reduziert sie stark, indem jede Komponente ihre eigene Datei erhält, aber Profiles, Permission Sets und einige andere Typen teilen sich weiterhin große Dateien und können in Konflikt geraten.

Kann ich Source-Driven Development mit Change Sets mischen?

Während eines Übergangs ja, aber das Ziel ist, manuelle Change Sets abzuschaffen, damit jede Änderung versioniert, geprüft und auf einen Commit zurückführbar ist.