Salesforce-Metadatenkonflikte lösen, ohne die Arbeit anderer zu verlieren

Kurze Antwort: Die meisten Salesforce-Merge-Konflikte sind keine echten Widersprüche. Es sind zwei Personen, die Unabhängiges in dieselbe überdimensionierte XML-Datei schreiben, oder dieselben Elemente, die in anderer Reihenfolge zurückkommen. Bei additiven Metadaten wie Profilen, Permission Sets, Layouts und Labels führen Sie beide Seiten zusammen; generiertes XML wie Flows dagegen niemals von Hand mergen: eine Version wählen und die andere Änderung im Flow Builder erneut vornehmen.

Warum unterscheiden sich Salesforce-Konflikte von gewöhnlichen Code-Konflikten?

Vier Eigenheiten der Plattform erklären fast alles.

• Die Reihenfolge der Elemente ist nicht garantiert. Die Metadata API kann dieselbe Datei mit anderer Elementreihenfolge liefern, und Git meldet dann einen Konflikt, obwohl sich nichts geändert hat. Das sind Falschkonflikte.
• Manche Typen sind eine einzige riesige Datei. Ein Profil enthält Berechtigungen für Objekte, Felder, Apex-Klassen und Seiten in einem Dokument. Zwei Personen an unabhängigen Features schreiben in dieselben Zeilen.
• Ein Teil des XML ist maschinell erzeugt. Eine Flow-Definition enthält Canvas-Koordinaten und generierte Elementnamen. Sie ist weder zum Bearbeiten noch zum Mergen von Hand gedacht.
• Git löst Text auf, Salesforce validiert Bedeutung. Ein textuell sauberer Merge kann trotzdem eine Datei erzeugen, die das Deployment ablehnt, oder eine gültige Datei, in der still eine Berechtigung fehlt.

Welche Metadatentypen kollidieren am häufigsten, und was tut man jeweils?

Profile und Permission Sets

Die schlimmsten Fälle, und fast immer additiv. Zwei Branches fügen je einen objectPermissions- oder fieldPermissions-Block hinzu, und die Ergänzungen landen nebeneinander. Beide Seiten übernehmen, dann anhand des Schlüsselelements (field, object, apexClass) entdoppeln und neu sortieren. Lösen Sie ein Profil nie, indem Sie eine Seite komplett übernehmen.

Gut zu wissen: Salesforce hat die Abschaffung von Berechtigungen in Profilen zurückgenommen (Salesforce-Help-Artikel 003834041). Profile verschwinden also nicht zu einem festen Termin, und das Problem löst sich nicht von selbst. Salesforce empfiehlt weiterhin ein Least-Privilege-Modell auf Basis von Permission Sets, und Berechtigungen aus Profilen herauszulösen verkleinert die Konfliktfläche tatsächlich, weil Permission Sets kleine Dateien pro Feature sind.

Flows

Nicht von Hand mergen. Das XML enthält generierte Elementnamen und Canvas-Koordinaten, ein zeilenweiser Merge erzeugt also etwas, das plausibel aussieht und falsch läuft. Wählen Sie eine Version als Sieger und wiederholen Sie die andere Änderung im Flow Builder.

Page Layouts und Lightning-Record-Seiten

Layout-XML listet jedes Element in Positionsreihenfolge, zwei Personen, die Felder in verschiedene Abschnitte einfügen, kollidieren also trotzdem, wenn die Abschnitte benachbart sind. Beide Seiten zusammenführen und danach prüfen, ob jedes layoutItem aus beiden Elternversionen überlebt hat. Reicht ein Konflikt in einer Lightning-Record-Seite über mehr als ein paar Zeilen, bauen Sie sie im Lightning App Builder neu, statt zu mergen.

Benutzerdefinierte Objekte und Felder

Speichert Ihr Repository ein Objekt als eine Datei, berührt jede Feldänderung genau diese Datei. Dekomponiertes Source-Format gibt jedem Feld eine eigene Datei und beseitigt die meisten dieser Konflikte, bevor sie entstehen.

Apex-Klassen und Trigger

Behandeln Sie sie als gewöhnliche Code-Konflikte, denn das sind sie. Logik auflösen, Tests erneut laufen lassen, und danach prüfen, ob die Klasse in den referenzierenden Profilen und Permission Sets weiterhin freigegeben ist.

Custom Labels und Übersetzungen

Einzelne alphabetische Dateien, rein additiv. Beide Seiten übernehmen und neu sortieren.

Wie liest man ein Salesforce-Metadaten-Diff, bevor man auflöst?

1. Klären, welche Seite welche ist. Beim Merge ist "ours" der Ziel-Branch und "theirs" der eingehende. Beim Rebase ist es umgekehrt. Diese Verwechslung ist der häufigste Weg, auf dem Arbeit verschwindet.
2. Reine Reihenfolgeunterschiede aussortieren. Enthalten beide Seiten dieselben Elemente in anderer Folge, hat niemand etwas geändert.
3. Nach Löschungen suchen, nicht nach Ergänzungen. Ergänzungen lassen sich meist gefahrlos kombinieren. Ein Block, der nur auf einer Seite existiert, ist die Änderung, die jemanden einen Tag kostet.
4. Auch gegen die Ziel-Org vergleichen, nicht nur gegen den Branch. Vielleicht hat jemand seit dem Abzweig direkt in der Org gearbeitet.
5. Vor dem Merge des Pull Requests validieren. XML, das sauber mergt, kann in der Deployment-Validierung trotzdem durchfallen.

Wie löst man einen Profilkonflikt, ohne die Berechtigung eines Kollegen zu löschen?

1. Die konfliktbehafteten Blöcke nach ihrem Schlüsselelement auflisten, nicht nach Zeilennummer.
2. Von jedem Block, der nur auf einer Seite vorkommt, beide Seiten behalten.
3. Taucht derselbe Schlüssel auf beiden Seiten mit unterschiedlichen Werten auf, Berechtigung für Berechtigung entscheiden und die Begründung im Pull Request festhalten.
4. Konfliktmarkierungen entfernen und die Datei neu sortieren, damit das nächste Diff klein bleibt.
5. Die zusammengeführte Datei gegen die Ziel-Org validieren.
6. Beide Autoren bestätigen lassen, dass ihre Berechtigung nach dem Merge noch existiert. Das dauert eine Minute und fängt, was das Review übersieht.

Wie löst man einen Flow-Konflikt sicher auf?

1. Die Version auf dem Ziel-Branch als Basis nehmen und die andere Seite in Git verwerfen.
2. Eine Sandbox mit dieser Basisversion öffnen und die Änderung der zweiten Person im Flow Builder erneut vornehmen.
3. Den Flow abrufen und die abgerufene Datei als Auflösung committen.
4. Vor dem Deployment prüfen, welche Version in der Ziel-Org aktiv ist, denn ein Flow-Deployment fügt eine Version hinzu, statt eine zu ersetzen.

Wie verhindert man den nächsten Konflikt?

• Kurzlebige Branches, in derselben Woche gemergt, in der sie entstehen.
• Ein Feature pro Pull Request.
• Berechtigungen in Permission Sets pro Feature statt in gemeinsamen Profilen.
• Objekte im dekomponierten Source-Format ablegen.
• Den Ziel-Branch in den eigenen holen, bevor der PR aufgeht, damit die Auflösung zur eigenen Zeit passiert, mit der eigenen Änderung noch im Kopf.

Dieser Leitfaden ist Teil unserer Salesforce-DevOps-Guides.

FAQ

Kann Git Salesforce-Metadatenkonflikte allein auflösen?

Nur textuell. Git kann nicht erkennen, dass zwei Profilblöcke unabhängig sind oder dass eine umsortierte Datei unverändert ist, meldet also Falschkonflikte und akzeptiert bereitwillig einen inhaltlich falschen Merge.

Was ist ein Falschkonflikt?

Ein Konflikt, bei dem beide Seiten dieselben Metadaten in anderer Reihenfolge enthalten. Die Metadata API garantiert keine Elementreihenfolge, zwei Abrufe können sich also ohne echte Änderung unterscheiden.

Darf man Flow-XML zur Konfliktlösung von Hand bearbeiten?

Nein. Eine Version wählen, die andere Änderung im Flow Builder wiederholen und das Abgerufene committen.

Warum kollidieren Profile, obwohl wir an ganz verschiedenen Features gearbeitet haben?

Ein Profil ist eine einzige Datei mit Berechtigungen für jedes Objekt, Feld und jede Klasse der Org, unabhängige Features landen deshalb auf benachbarten Zeilen.

Wie prüfe ich, dass beim Merge nichts verloren ging?

Die zusammengeführte Datei gegen beide Elternversionen diffen, bestätigen, dass jedes Schlüsselelement beider Seiten überlebt hat, und vor dem Merge das Deployment gegen die Ziel-Org validieren.