Salesforce-metadataconflicten oplossen zonder iemands werk kwijt te raken

Kort antwoord: de meeste Salesforce-mergeconflicten zijn geen echte meningsverschillen. Het zijn twee mensen die losstaande dingen toevoegen aan hetzelfde veel te grote XML-bestand, of dezelfde elementen die in een andere volgorde terugkomen. Combineer bij additieve metadata zoals profielen, permission sets, layouts en labels beide kanten, en merge gegenereerde XML zoals Flows nooit met de hand: kies één versie en breng de andere wijziging opnieuw aan in Flow Builder.

Waarom verschillen Salesforce-mergeconflicten van gewone codeconflicten?

Vier eigenaardigheden van het platform veroorzaken bijna alles.

• De volgorde van elementen ligt niet vast. De Metadata API kan hetzelfde bestand met elementen in een andere volgorde teruggeven, dus meldt Git een conflict terwijl er niets veranderd is. Dat zijn valse conflicten.
• Sommige types zijn één gigantisch bestand. Een profiel bevat rechten voor objecten, velden, Apex-klassen en pagina's in één document. Twee mensen aan losstaande features schrijven naar dezelfde regels.
• Sommige XML is machinaal gegenereerd. Een Flow-definitie bevat canvascoördinaten en gegenereerde elementnamen. Die is niet bedoeld om met de hand te bewerken, en niet veilig om met de hand te mergen.
• Git lost tekst op, Salesforce valideert betekenis. Een tekstueel schone merge kan alsnog een bestand opleveren dat de deployment weigert, of een geldig bestand waarin stilletjes iemands recht verdwijnt.

Welke metadatatypes conflicteren het meest, en wat doe je per type?

Profielen en permission sets

De grootste boosdoeners, en bijna altijd additief. Twee branches voegen elk een objectPermissions- of fieldPermissions-blok toe en die toevoegingen komen naast elkaar te staan. Neem beide kanten, ontdubbel daarna op het sleutelelement (field, object, apexClass) en sorteer opnieuw. Los een profiel nooit op door één kant integraal te accepteren.

Goed om te weten: Salesforce heeft het uitfaseren van rechten in profielen geannuleerd (Salesforce Help-artikel 003834041), dus profielen verdwijnen niet op een vaste datum en dit probleem lost zichzelf niet op. Salesforce adviseert nog steeds een least-privilege-model op basis van permission sets, en rechten uit profielen halen verkleint het conflictoppervlak daadwerkelijk, omdat permission sets kleine bestanden per feature zijn.

Flows

Merge ze niet met de hand. De XML bevat gegenereerde elementnamen en canvascoördinaten, dus een merge op regelniveau levert iets op dat er aannemelijk uitziet en zich verkeerd gedraagt. Kies één versie als winnaar en breng de andere wijziging opnieuw aan in Flow Builder.

Page layouts en Lightning record pages

Layout-XML somt elk item op volgorde van positie op, dus twee mensen die velden aan verschillende secties toevoegen botsen alsnog als die secties naast elkaar liggen. Combineer beide kanten en controleer daarna of elk layoutItem uit beide ouders bewaard is gebleven. Loopt een conflict in een Lightning record page over meer dan een paar regels, bouw hem dan opnieuw in de Lightning App Builder in plaats van te mergen.

Custom objects en velden

Slaat je repo een object op als één bestand, dan raakt elke veldwijziging dat bestand. Gedecomposeerd source format geeft elk veld een eigen bestand en haalt de meeste van deze conflicten weg voordat ze ontstaan.

Apex-klassen en triggers

Behandel deze als gewone codeconflicten, want dat zijn ze. Los de logica op, draai de tests opnieuw, en controleer daarna of de klasse nog steeds is toegekend in de profielen en permission sets die ernaar verwijzen.

Custom labels en vertalingen

Enkele alfabetische bestanden, puur additief. Neem beide kanten en sorteer opnieuw.

Hoe lees je een Salesforce-metadatadiff voordat je iets oplost?

1. Stel vast welke kant welke is. Bij een merge is "ours" de doelbranch en "theirs" de binnenkomende. Bij een rebase wisselen ze om. Dit omdraaien is de meest voorkomende manier waarop werk verdwijnt.
2. Filter verschillen weg die alleen over volgorde gaan. Bevatten beide kanten dezelfde elementen in een andere volgorde, dan heeft niemand iets veranderd.
3. Jaag op verwijderingen, niet op toevoegingen. Toevoegingen zijn meestal veilig te combineren. Een blok dat aan één kant ontbreekt is de wijziging die iemand een dag kost.
4. Vergelijk ook met de doel-org, niet alleen met de branch. Iemand kan sinds het aftakken direct in de org hebben gewerkt.
5. Valideer voordat je de pull request merget. XML die schoon merget kan alsnog zakken op deploymentvalidatie.

Hoe los je een profielconflict op zonder het recht van een collega te wissen?

1. Inventariseer de conflicterende blokken op hun sleutelelement in plaats van op regelnummer.
2. Behoud beide kanten van elk blok dat maar aan één kant voorkomt.
3. Komt dezelfde sleutel aan beide kanten voor met andere waarden, beslis dan per recht en leg de afweging vast in de pull request.
4. Haal de conflictmarkeringen weg en sorteer het bestand opnieuw, zodat de volgende diff klein blijft.
5. Valideer het gemergede bestand tegen de doel-org.
6. Vraag beide auteurs te bevestigen dat hun recht na de merge nog bestaat. Kost een minuut en vangt wat review mist.

Hoe los je een Flow-conflict veilig op?

1. Neem de versie die al op de doelbranch staat als basis en verwerp de andere kant in Git.
2. Open een sandbox met die basisversie en breng de wijziging van de tweede auteur opnieuw aan in Flow Builder.
3. Haal de flow op en commit het opgehaalde bestand als oplossing.
4. Controleer welke versie actief is in de doel-org voordat je deployt, want een flow deployen voegt een versie toe in plaats van er een te vervangen.

Hoe voorkom je het volgende conflict?

• Kortlevende branches, gemerged in dezelfde week dat ze zijn afgetakt.
• Eén feature per pull request.
• Rechten in permission sets per feature in plaats van in gedeelde profielen.
• Objecten opgeslagen in gedecomposeerd source format.
• Haal de doelbranch binnen in de jouwe vóór je de PR opent, zodat je oplost op je eigen moment met je eigen wijziging nog vers in het geheugen.

Deze gids maakt deel uit van onze Salesforce DevOps-gidsen.

FAQ

Kan Git Salesforce-metadataconflicten zelf oplossen?

Alleen tekstueel. Git kan niet zien dat twee profielblokken los van elkaar staan of dat een herordend bestand ongewijzigd is, dus meldt het valse conflicten en accepteert het zonder morren een merge die inhoudelijk fout is.

Wat is een vals conflict?

Een conflict waarbij beide kanten dezelfde metadata in een andere volgorde bevatten. De Metadata API garandeert geen elementvolgorde, dus twee ophaalacties kunnen verschillen zonder dat er iets veranderd is.

Mag ik Flow-XML ooit met de hand aanpassen om een conflict op te lossen?

Nee. Kies één versie, breng de andere wijziging opnieuw aan in Flow Builder en commit wat je ophaalt.

Waarom conflicteren profielen terwijl we aan totaal verschillende features werkten?

Een profiel is één bestand met rechten voor elk object, veld en elke klasse in de org, dus losstaande features schrijven naar aangrenzende regels.

Hoe controleer ik dat er bij de merge niets verloren is gegaan?

Vergelijk het gemergede bestand met beide ouderversies, bevestig dat elk sleutelelement van beide kanten bewaard is, en valideer de deployment tegen de doel-org voordat je merget.