Source-driven Development in Salesforce, erklaert

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

Was ist Source-driven Development in Salesforce?

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

Drei praktische Eigenschaften kommen mit:

• Historie. Jede Aenderung hat Autor, Zeitpunkt und Grund.
• Umkehrbarkeit. Zuruecknehmen heisst, einen bekannten guten Zustand zu deployen, nicht ihn aus dem Gedaechtnis zu rekonstruieren.
• Parallelitaet. Zwei Personen koennen am selben Objekt arbeiten, ohne dass eine die andere stillschweigend ueberschreibt, 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 zufaellig behalten hat. Source-driven: die vollstaendige Aenderungshistorie, dauerhaft.
• Wie Sie zuruecknehmen. Org zu Org: den vorherigen Zustand manuell nachbauen. Source-driven: den vorherigen Commit deployen.
• Wer pruefen kann. Org zu Org: wer Adminrechte hat. Source-driven: jeder mit Leserecht auf das Repository, auch Pruefer, 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 festhaelt, welche Komponenten sich in einer Org oder im lokalen Projekt seit dem letzten Abgleich geaendert haben, damit Sie nur das holen, was sich wirklich bewegt hat, statt alles zu retrieven und einen Diff zu lesen.

Woran Teams stossen, ist die Abdeckung. Source Tracking gibt es in Scratch Orgs und in Developer- und Developer-Pro-Sandboxes. Es gibt es nicht ueberall, also muss ein Source-driven-Modell die Umgebungen beantworten, die keine Aenderungen fuer Sie mitschreiben: Full Sandboxes, Partial Copies und Produktion. Genau dort entstehen undokumentierte Aenderungen.

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 Feldaenderung schreibt eine grosse Datei neu, der Diff traegt 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 ueberstehen.

Was passiert, wenn Org und Repository auseinanderlaufen?

Das ist die Frage, die die meisten Erklaerungen auslassen, und die entscheidet, ob das Modell den Kontakt mit einem echten Salesforce-Team ueberlebt. Irgendjemand aendert immer etwas in der Produktion: ein Hotfix um Mitternacht, ein Admin, der einen Picklist-Wert ergaenzt, ein Package-Upgrade, das committete Metadaten ueberschreibt.

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

1. Wer gewinnt. Das Repository gewinnt, per Richtlinie. Eine Aenderung ausserhalb des Wegs ist damit nicht "verloren", sondern wird versoehnt: abgeholt, mit Begruendung commitet und dann aus dem Branch neu deployt.
2. Wie Sie es merken. Lassen Sie Drift-Erkennung planmaessig gegen die Produktion laufen. Divergenz zum Release-Zeitpunkt zu entdecken heisst, sie zu spaet zu entdecken.
3. Was bewusst ausserhalb liegt. Manche Metadaten sind wirklich umgebungsspezifisch oder gehoeren einem installierten Package. Schreiben Sie diese Ausschlussliste auf. Eine ehrliche Ausschlussliste schlaegt ein Repository, dem alle leise misstrauen.

Wie fuehrt 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 aendert.
3. Setzen Sie ein Tor vor die Produktion. Selbst eine manuelle Freigabe auf einem Branch zaehlt. Wahrheit ohne Tor driftet binnen eines Monats zurueck.
4. Halten Sie die taegliche Oberflaeche vertraut. Admins arbeiten weiter in einem Ticket oder Work Item; Commit, Branch und Merge gehoeren darunter.
5. Fuegen Sie Drift-Erkennung zuletzt hinzu. Sobald die Pipeline Vertrauen geniesst, zeigt sie Ihnen, wo das Modell leckt.

FAQ

Muss jeder Admin dafuer Git lernen?

Nein. Es verlangt, dass das Repository massgeblich 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 fuer seinen Umfang wirklich massgeblich ist, schlaegt ein vollstaendiges, 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 zurueck. Dokumentieren Sie sie als ausgeschlossen und steuern Sie sie per Verfahren, statt so zu tun, als deckte das Repository sie ab.

Serpent ist genau fuer das hier beschriebene Team gebaut: Das Repository bleibt die Quelle der Wahrheit, waehrend Admins und Berater in Tickets arbeiten, mit Delta-Deployments, Drift-Erkennung und Rollback per Klick obendrauf. Weitere Referenzleitfaeden finden Sie in SF Guides.