Von Change Sets zu Source Control in Salesforce wechseln

Kurz gesagt: Um von Change Sets zu Source Control zu wechseln, legst du die Metadaten deiner Org in ein Git-Repository, nutzt eine source-getrackte Entwicklungsumgebung und deployst ueber eine Pipeline, statt Komponenten von Hand auszuwaehlen. Mach es schrittweise: aktiviere Source Tracking, pilotiere ein Team auf Git mit einer validate-only Pipeline und ziehe Change Sets Bereich fuer Bereich zurueck.

Salesforce empfiehlt Kunden inzwischen selbst, das Org-zu-Org-Release-Modell hinter sich zu lassen, und die meisten Anleitungen erklaeren, warum Change Sets zu kurz greifen. Wenige geben dir den tatsaechlichen Migrationspfad. Diese Anleitung ist dieser Pfad: ein wiederholbares Playbook, das du ohne Auslieferungsstopp ausfuehren kannst.

Was bedeutet der Wechsel von Change Sets zu Source Control?

Es bedeutet, die Quelle der Wahrheit fuer deine Metadaten aus der Org in ein Versionskontrollsystem zu verlagern, meist Git. Change Sets kopieren Komponenten von Org zu Org und hinterlassen keine Historie. Source Control speichert jedes Layout, jeden Flow, jede Permission Set und jede Apex-Klasse als versionierte Dateien, sodass du branchen, reviewen, deployen und zuruckrollen kannst. Die Org wird zum Deployment-Ziel statt zum Master-Datensatz.

Warum von Change Sets weg?

Change Sets sind ein guter Startpunkt und bleiben fuer kleine Teams nuetzlich. Mit dem Wachstum stossen sie an eine Grenze:

• Keine Versionskontrolle und keine Historie, wer was geaendert hat.
• Kein automatisches Rollback, wenn ein Deployment schiefgeht.
• Kein Code-Review, bevor Aenderungen landen.
• Manuelle Auswahl jeder Komponente, langsam und fehleranfaellig.
• Nicht unterstuetzte Metadatentypen und unveraenderliche, nicht editierbare Uploads.

Wie migrierst du von Change Sets zu Source Control?

Fuehre diese Schritte der Reihe nach aus. Ziel ist eine funktionierende Pipeline fuer einen Bereich, bevor du ausweitest.

1. Erstelle das Repository. Richte ein Git-Repo ein und einige dich auf ein Branching-Modell, das dein Team versteht.
2. Aktiviere Source Tracking in der Produktion. Neue Developer- und Developer-Pro-Sandboxes erben es dann, was die automatische Aenderungserfassung ermoeglicht.
3. Lege eine Baseline an. Hole deine bestehenden Org-Metadaten mit der Salesforce CLI und committe sie als ersten Snapshot der Wahrheit.
4. Konvertiere ins Source-Format. Nutze die CLI, um grosse Metadatendateien in kleinere, mergebare Source-Dateien zu zerlegen, die Konflikte reduzieren.
5. Pilotiere ein Team. Verlagere ein einzelnes Team oder Projekt auf Feature-Branches und ein validate-only Deployment, waehrend alle anderen weiter Change Sets nutzen.
6. Fuege Continuous Integration hinzu. Verdrahte eine Pipeline, die jeden Pull Request validiert und gemergte Source in die naechste Umgebung deployt.
7. Ziehe Change Sets nach Bereich zurueck. Sobald die erste Pipeline vertraut ist, schalte diesen Bereich von Change Sets ab und wiederhole es fuer das naechste Team.

Change Sets vs. Source Control: was aendert sich wirklich?

• Quelle der Wahrheit: die Org wird zum Deployment-Ziel; das Repository haelt den verbindlichen Stand.
• Aenderungserfassung: manuelles Ankreuzen wird automatisches Source Tracking.
• Review: kein Review wird zu Pull Requests.
• Deploy: manuelle Klicks werden zu einer wiederholbaren Pipeline.
• Wiederherstellung: kein Rollback wird Zuruecksetzen-und-neu-Deployen aus der Historie.

Welche Tools solltest du nutzen?

Die kostenlose Basis ist Salesforces eigene: die Salesforce CLI, Salesforce DX und DevOps Center, das Change Sets durch eine Git-gestuetzte Oberflaeche ersetzt und mit GitHub und Bitbucket integriert. Wenn du verwaltete Pipelines, Backups, metadaten-bewusste Diffs und Quality Gates brauchst, bauen Plattformen wie Serpent, Copado, Gearset, AutoRABIT, Flosum, Salto und Blue Canvas auf demselben Git-Fundament auf. Starte kostenlos und adoptiere eine Plattform, wenn der Prozess, nicht das Tooling, dein Engpass ist. Genau diesen Umstiegsweg beschreiben wir unter Change Sets versus Serpent. Weitere Salesforce-DevOps-Anleitungen findest du in den Serpent-Guides.

Wie vermeidest du haeufige Migrationsfehler?

Versuche keinen Big-Bang-Umstieg. Migriere einen Bereich nach dem anderen und lass Change Sets parallel laufen, bis jede Pipeline erprobt ist. Aktiviere Source Tracking, bevor du baust, nicht danach, sonst erfassen deine ersten Sandboxes keine Aenderungen. Und lege die Baseline der gesamten Org an, bevor jemand einen Feature-Branch beginnt, damit dein Repository ab Tag eins die Produktion abbildet, statt von ihr abzudriften.

FAQ

Muss ich Change Sets sofort einstellen?

Nein. Migriere Bereich fuer Bereich und behalte Change Sets fuer Teams, die noch nicht gewechselt haben, damit die Auslieferung nie einfriert.

Welche Umgebungen unterstuetzen Source Tracking?

Scratch Orgs sowie Developer- und Developer-Pro-Sandboxes unterstuetzen Source Tracking; Partial-Copy- und Full-Sandboxes nicht.

Reicht DevOps Center, oder brauche ich ein kostenpflichtiges Tool?

DevOps Center ist ein kostenloser, Git-gestuetzter Startpunkt. Ergaenze eine kommerzielle Plattform, wenn du verwaltete Pipelines, Backups oder fortgeschrittene Quality Gates brauchst.

Wie lege ich die Baseline einer bestehenden Org an?

Hole die Metadaten der Org mit der Salesforce CLI, konvertiere sie ins Source-Format und committe sie als erste Version in deinem Repository.