Source-driven Development in Salesforce, erklärt

Zuerst die Definition: Source-driven Development ist das Modell, in dem Ihr Git-Repository und keine Org die Quelle der Wahrheit für Salesforce-Konfiguration und -Code ist. Orgs werden zu ersetzbaren Umgebungen, in die Sie aus dem Repository deployen, statt zu Orten, zwischen denen Sie Änderungen kopieren. Alles Weitere in diesem Leitfaden folgt aus diesem einen Satz.

Was ist Source-driven Development in Salesforce?

In diesem Modell landet jede Änderung zuerst in der Versionsverwaltung und erst danach in einer Org. Das Repository hält den gewollten Zustand der Org. Ein Deployment ist der Akt, eine Org an diese Absicht anzugleichen.

Drei praktische Eigenschaften kommen mit:

• Historie. Jede Änderung hat Autor, Zeitpunkt und Grund.
• Umkehrbarkeit. Zurücknehmen heißt, einen bekannten guten Zustand zu deployen, nicht ihn aus dem Gedächtnis zu rekonstruieren.
• Parallelität. Zwei Personen können am selben Objekt arbeiten, ohne dass eine die andere stillschweigend überschreibt, weil der Merge explizit ist.

Worin unterscheidet es sich vom Org-zu-Org-Deployment?

Org-zu-Org-Deployment, ob per Change Set oder per direktem Vergleich zweier Orgs, nimmt eine lebende Org als Referenz. Das ist der eigentliche Unterschied, und er hat Folgen.

• Wo die Wahrheit wohnt. Org zu Org: die Quell-Org. Source-driven: der Branch.
• Was ein Release ist. Org zu Org: eine von Hand zusammengestellte Komponentenliste. Source-driven: ein Diff zwischen zwei Commits.
• Welche Historie Sie bekommen. Org zu Org: was das Deployment-Log zufällig behalten hat. Source-driven: die vollständige Änderungshistorie, dauerhaft.
• Wie Sie zurücknehmen. Org zu Org: den vorherigen Zustand manuell nachbauen. Source-driven: den vorherigen Commit deployen.
• Wer prüfen kann. Org zu Org: wer Adminrechte hat. Source-driven: jeder mit Leserecht auf das Repository, auch Prüfer, die nie an die Produktion sollten.

Beachten Sie, was nicht auf der Liste steht: Geschwindigkeit. Source-driven Development ist nicht automatisch schneller. Es ist wiederholbar, und das ist eine andere, haltbarere Eigenschaft.

Was ist Source Tracking und wo funktioniert es?

Source Tracking ist die Plattformfunktion, die festhält, welche Komponenten sich in einer Org oder im lokalen Projekt seit dem letzten Abgleich geändert haben, damit Sie nur das holen, was sich wirklich bewegt hat, statt alles zu retrieven und einen Diff zu lesen.

Woran Teams stoßen, ist die Abdeckung. Source Tracking gibt es in Scratch Orgs und in Developer- und Developer-Pro-Sandboxes. Es gibt es nicht überall, also muss ein Source-driven-Modell die Umgebungen beantworten, die keine Änderungen für Sie mitschreiben: Full Sandboxes, Partial Copies und Produktion. Genau dort entstehen undokumentierte Änderungen.

Source Format oder Metadata Format: was commiten Sie?

Commiten Sie Source Format. Die beiden Formate beschreiben dieselben Metadaten unterschiedlich:

• Metadata Format ist die Form der Metadata API: breite Dateien pro Objekt plus ein package.xml-Manifest. Eine Feldänderung schreibt eine große Datei neu, der Diff trägt also das ganze Objekt und Reviews werden laut.
• Source Format zerlegt diese Struktur: jedes Feld, jede Validierungsregel und jede Listenansicht bekommt eine eigene Datei im Ordnerbaum, mit Package-Verzeichnissen in sfdx-project.json.

Der Effekt liegt in Review und Merge, nicht in der Funktion. Kleine Dateien erzeugen lesbare Diffs und deutlich weniger Konflikte, wenn zwei Personen dasselbe Objekt anfassen, und genau diese Situation soll das Modell überstehen.

Source Format zerlegt allerdings nicht alles. Profiles, Permission Sets und Sharing Rules landen weiterhin in großen, gemeinsam genutzten Dateien, sodass zwei Personen, die dasselbe Profile bearbeiten, trotzdem kollidieren können. Legen Sie vor der Migration fest, wem diese Dateien gehören. Source Tracking deckt außerdem nicht jeden Metadatentyp ab: Prüfen Sie den Metadata Coverage Report, bevor Sie annehmen, dass ein Typ verfolgt wird.

Was passiert, wenn Org und Repository auseinanderlaufen?

Das ist die Frage, die die meisten Erklärungen auslassen, und die entscheidet, ob das Modell den Kontakt mit einem echten Salesforce-Team überlebt. Irgendjemand ändert immer etwas in der Produktion: ein Hotfix um Mitternacht, ein Admin, der einen Picklist-Wert ergänzt, ein Package-Upgrade, das committete Metadaten überschreibt.

Entscheiden Sie diese drei Punkte vor der Migration, nicht danach:

1. Wer gewinnt. Das Repository gewinnt, per Richtlinie. Eine Änderung außerhalb des Wegs ist damit nicht "verloren", sondern wird versöhnt: abgeholt, mit Begründung commitet und dann aus dem Branch neu deployt.
2. Wie Sie es merken. Lassen Sie Drift-Erkennung planmäßig gegen die Produktion laufen. Divergenz zum Release-Zeitpunkt zu entdecken heißt, sie zu spät zu entdecken.
3. Was bewusst außerhalb liegt. Manche Metadaten sind wirklich umgebungsspezifisch oder gehören einem installierten Package. Schreiben Sie diese Ausschlussliste auf. Eine ehrliche Ausschlussliste schlägt ein Repository, dem alle leise misstrauen.

Wie führt man das ohne Git-erfahrenes Team ein?

Die meisten Salesforce-Teams bestehen aus Admins und Beratern, nicht aus CLI-Nutzern, und genau dort bleiben Migrationen stecken. Ordnen Sie die Schritte so, dass niemand Git lernen muss, um weiterzuarbeiten:

1. Starten Sie an einer Package-Grenze. Ein Team, ein Satz Metadaten. Versuchen Sie nicht, in Woche eins die ganze Org zu commiten.
2. Holen Sie im Source Format ab und erreichen Sie ein sauberes Deployment dieses Umfangs in eine Sandbox, bevor jemand seine Gewohnheiten ändert.
3. Setzen Sie ein Tor vor die Produktion. Selbst eine manuelle Freigabe auf einem Branch zählt. Wahrheit ohne Tor driftet binnen eines Monats zurück.
4. Halten Sie die tägliche Oberfläche vertraut. Admins arbeiten weiter in einem Ticket oder Work Item; Commit, Branch und Merge gehören darunter.
5. Fügen Sie Drift-Erkennung zuletzt hinzu. Sobald die Pipeline Vertrauen genießt, zeigt sie Ihnen, wo das Modell leckt.

Noch mit Change Sets unterwegs? Starten Sie mit dem Wechsel von Change Sets zu Source Control und automatisieren Sie dann die Auslieferung mit einer Salesforce-CI/CD-Pipeline auf GitHub Actions. Oder lassen Sie uns die Migration mit Ihnen durchführen.

FAQ

Muss jeder Admin dafür Git lernen?

Nein. Es verlangt, dass das Repository maßgeblich ist. Welche Menschen direkt mit Git arbeiten, ist eine Werkzeugfrage, keine Eigenschaft des Modells.

Muss ich die ganze Org auf einmal ins Source Format bringen?

Nein. Konvertieren Sie pro Package-Grenze oder pro Team. Ein Teil-Repository, das für seinen Umfang wirklich maßgeblich ist, schlägt ein vollständiges, dem niemand traut.

Ist Source-driven Development dasselbe wie CI/CD?

Nein. Source-driven Development entscheidet, wo die Wahrheit wohnt. CI/CD automatisiert deren Transport in Orgs. Das Erste geht ohne das Zweite, umgekehrt kaum sinnvoll.

Und Metadaten, die sich nicht versionieren lassen?

Manche Einstellungen und Package-eigene Komponenten kommen nicht sauber zurück. Dokumentieren Sie sie als ausgeschlossen und steuern Sie sie per Verfahren, statt so zu tun, als deckte das Repository sie ab.

Ist Source-driven Development dasselbe wie Salesforce DX?

Nein. Salesforce DX ist das Werkzeug und das Dateiformat; Source-driven Development ist die Praxis, das Repository statt der Org zur Quelle der Wahrheit zu machen.

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

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

Serpent ist genau für das hier beschriebene Team gebaut: Das Repository bleibt die Quelle der Wahrheit, während Admins und Berater in Tickets arbeiten, mit Delta-Deployments, Drift-Erkennung und Rollback per Klick obendrauf. Weitere Referenzleitfäden finden Sie in SF Guides.