Von Change Sets zur Versionskontrolle wechseln (Schritt für Schritt)

Kurz gesagt: Um von Change Sets zur Versionskontrolle zu wechseln, holen Sie die Metadaten Ihrer Org in ein Salesforce-DX-Projekt, committen sie als einzige Quelle der Wahrheit in ein Git-Repository, führen ein Modell mit einem Branch je Umgebung ein und liefern über eine automatisierte Pipeline aus, statt Change Sets von Org zu Org zu klicken. Gehen Sie schrittweise vor: Beginnen Sie mit einem Projekt, bewähren Sie den Ablauf und übertragen Sie dann den Rest.

Warum überhaupt von Change Sets zur Versionskontrolle?

Change Sets sind ein manuelles Org-zu-Org-Werkzeug mit drei harten Grenzen: keine Versionshistorie, kein Rollback und kein Audit-Protokoll. Jede Auslieferung ist ein Neuschreiben der Metadaten ohne Aufzeichnung, was sich geändert hat oder warum, und sie bewegen sich nur zwischen Orgs mit derselben Produktion. Salesforce selbst empfiehlt Teams inzwischen, DevOps-Praktiken einzuführen und das Org-zu-Org-Release-Modell hinter sich zu lassen.

Versionskontrolle behebt alle drei. Git gibt Ihnen eine einzige Quelle der Wahrheit, eine vollständige Historie jeder Änderung, Branching und Merging für paralleles Arbeiten und die Fähigkeit, in Minuten auf einen bekannten guten Stand zurückzurollen. Es ist das Fundament, auf dem jede andere DevOps-Praxis aufbaut.

Wann ist es Zeit für den Wechsel?

Erwägen Sie den Wechsel, sobald einer dieser Punkte zutrifft:

• Mehr als eine Person nimmt parallel Änderungen vor.
• Sie betreiben drei oder mehr Umgebungen.
• Sie liefern häufige oder Notfall-Releases aus.
• Sie haben Compliance-Anforderungen - Genehmigungen, Funktionstrennung, Audit-Protokolle.

Wenn zwei oder mehr zutreffen, kosten Change Sets Sie bereits mehr, als sie einsparen.

Wie wechseln Sie Schritt für Schritt von Change Sets zur Versionskontrolle?

1. Wandeln Sie Ihre Metadaten in das Source-Format um. Nutzen Sie die Salesforce CLI, um Metadaten in ein Salesforce-DX-Projekt (SFDX) zu holen, sodass Ihre Org als Dateien statt als Change-Set-Momentaufnahme beschrieben wird.
2. Erstellen Sie ein Git-Repository. Committen Sie dieses Projekt als Ausgangsbasis - die erste einzige Quelle der Wahrheit für die Org.
3. Wählen Sie ein Branch-Modell. Am einfachsten ist ein langlebiger Branch je Umgebung (zum Beispiel dev, uat, main), wobei Feature-Branches über Pull Requests gemergt werden.
4. Automatisieren Sie die Auslieferung. Richten Sie eine Pipeline ein, die beim Merge von jedem Branch in seine Umgebung ausliefert und Validierung sowie Tests automatisch ausführt, statt manueller Change-Set-Uploads.
5. Ergänzen Sie Tests und Prüfungen. Verlangen Sie, dass Apex-Tests, Code-Review und Validierung bestehen, bevor ein Merge die Produktion erreicht.
6. Legen Sie Change Sets still. Behalten Sie sie nur als Notfall-Rückfall, sobald die Pipeline vertrauenswürdig ist.

Sie müssen das nicht per Big Bang tun. Beginnen Sie mit einem einzelnen Projekt oder Team, bewähren Sie den Ablauf und übertragen Sie dann den Rest der Org.

Welche Werkzeuge brauchen Sie für den Wechsel?

Mindestens: einen Git-Host (GitHub, GitLab oder Bitbucket), die Salesforce CLI und ein Salesforce-DX-Projekt. Das kostenlose DevOps Center von Salesforce ergänzt Versionskontrolle, Work Items und Änderungsverfolgung über eine Point-and-Click-Oberfläche, ein solider erster Schritt für Low-Code-Teams. Wachsende Teams wechseln meist zu einer dedizierten Plattform, die Versionskontrolle, automatisierte Tests und Rollback bündelt, damit Admins nicht in der CLI leben müssen. Sehen Sie in unserer SF-Guides-Bibliothek, wie die Teile zusammenpassen.

Für den Denkwandel hinter dem Wechsel lesen Sie den Wandel, den Sie nicht mehr ignorieren können, und wenn Sie bereit sind, einen wiederholbaren Release-Ablauf zu bauen, geht unser Playbook von Change Sets zu Continuous Delivery weiter.

Wie vermeiden Sie die häufigen Migrationsfehler?

• Holen Sie nicht alles auf einmal. Beginnen Sie mit den Metadaten, die Ihr Team aktiv ändert, und erweitern Sie dann.
• Achten Sie auf Profile und Permission Sets. Sie sind die kniffligsten Metadaten für sauberes Versionieren, planen Sie sie bewusst.
• Betreiben Sie Change Sets und Git nicht dauerhaft parallel. Zwei Quellen der Wahrheit machen den Zweck zunichte.
• Nehmen Sie die Admins mit. Der Wechsel scheitert häufiger an der Kultur als am Werkzeug.

Wenn Sie bereit sind, ohne den manuellen Aufwand zu wechseln, führt Sie unser Migrationsleitfaden den ganzen Weg entlang.

FAQ

Kann ich ohne Programmieren von Change Sets zu Git wechseln?

Weitgehend ja. Das DevOps Center und Drittanbieter-Plattformen bieten Point-and-Click-Versionskontrolle, auch wenn jemand die erste CLI-Abfrage noch ausführt, um das Repository zu befüllen.

Was ist ein Salesforce-DX-Projekt?

Es ist die Source-Format-Darstellung der Metadaten Ihrer Org als Dateien und Ordner, abgerufen mit der Salesforce CLI, die Git dann verfolgt und versioniert.

Ist das DevOps Center ein vollständiger Ersatz für Change Sets?

Für viele Teams ja. Es ergänzt Versionskontrolle und Änderungsverfolgung über Git, doch größere Teams brauchen oft die automatisierten Tests und das Rollback, die dedizierte Plattformen bieten.

Wie lange dauert die Migration?

Ein einzelnes Projekt kann in Tagen wechseln. Eine vollständige Org mit mehreren Teams ist meist ein phasenweiser Rollout über Wochen, Umgebung für Umgebung.