Git-branches koppelen aan Salesforce-sandboxes

Git-branches koppelen aan Salesforce-sandboxes betekent bepalen welke branch de bron van waarheid is voor elke omgeving, zodat een wijziging van dev naar productie beweegt via beoordeelde merges in plaats van org-naar-org deployments. Langlevende branches koppel je aan persistente sandboxes; kortlevende feature branches aan scratch orgs en developer-sandboxes. Klopt de koppeling, dan is promoveren gewoon een merge. Klopt ze niet, dan erf je merges van merges en stille drift.

Deze gids gaat over de koppelmechanica, niet over de keuze van het model. Twijfel je nog tussen trunk-based, GitFlow en branch per omgeving, begin dan met Git-branchingstrategieen voor Salesforce-teams: een beslisregel, en kom hier terug om het aan je orgs te koppelen.

Welk sandboxtype hoort bij welke branch?

Een branch is pas echt als er een org is om hem in te deployen en te testen. Koppel elke branch aan het sandboxtype dat past bij zijn doel en refresh-ritme:

• Feature branch aan een scratch org of Developer-sandbox. Wegwerpbaar, per ticket aangemaakt, weggegooid bij de merge.
• Integration branch aan een Developer Pro-sandbox, waar featurewerk samenkomt en samen getest wordt.
• UAT branch aan een Partial Copy- of Full-sandbox, zodat businessusers tegen representatieve data testen.
• Main branch aan productie, altijd beschermd en alleen bijgewerkt via een beoordeelde merge.

Het refresh-ritme begrenst hoeveel langlevende branches je echt kunt ondersteunen. Salesforce hanteert minimale refreshintervallen van een dag voor Developer en Developer Pro, vijf dagen voor Partial Copy en 29 dagen voor Full, dus een branch die je niet kunt refreshen is een branch die je niet kunt vertrouwen.

Hoe verloopt promotie tussen branches?

Promoveren is een merge, geen herdeploy. Een wijziging start op een feature branch en klimt de keten op naarmate ze elke poort passeert:

1. Maak een feature branch, ontwikkel tegen zijn scratch org of Developer-sandbox.
2. Open een pull request naar de integration branch; bij de merge deploy je naar de integration-sandbox.
3. Merge integration naar de UAT branch voor business-sign-off in de Partial Copy- of Full-sandbox.
4. Merge UAT naar main; de deploy naar productie is dezelfde metadata die UAT al passeerde.

De regel die de meeste pijn bespaart: laat een branch die aan productie gekoppeld is nooit een directe commit accepteren. Alles bereikt hem via een beoordeelde merge, dus de branchhistorie is ook je deploymenthistorie.

Hoe houdt source tracking een branch en zijn org in sync?

Source tracking registreert welke metadata in een sandbox veranderde, zodat je die wijzigingen in de branch pullt in plaats van een volledige retrieve te gokken. Deploy vanuit git naar de gekoppelde org, en laat source tracking alles markeren wat een admin direct in die org wijzigde. Die lus houdt de branch als bron van waarheid en voorkomt dat de org en de branch stilletjes uiteenlopen.

Data, org-brede instellingen en licenties leven buiten de repo, dus de koppeling dekt alleen metadata. Behandel die als omgevingsconfiguratie die je apart seedt, niet als iets wat een branch kan promoveren.

Wat zijn de veelvoorkomende koppelfouten?

• Een langlevende branch per developer-sandbox. Elke extra langlevende branch is weer een mergedoel dat drift. Houd feature branches kort en wegwerpbaar.
• Org naar org deployen en het promotie noemen. Als de branch niet is wat je deployt, stopt de branchhistorie met matchen wat live staat.
• Een UAT branch aan een Developer-sandbox koppelen. Zonder representatieve data test de sign-off het verkeerde en mist hij datagevormde bugs.
• Admins productie direct laten wijzigen. Een klik in productie die nooit in git komt maakt je koppeling fictie bij de volgende deploy.

Laat de koppeling zichzelf afdwingen

Een koppeling die in een onboardingdocument leeft, breekt in de eerste drukke releaseweek. Serpent draait een ticketgestuurde workflow met Git op de achtergrond, zodat de branch, zijn sandbox en het promotiepad uit het ticket komen in plaats van uit het geheugen. Meer pijplijngidsen staan in onze SF Guides-bibliotheek.

FAQ

Heb ik een branch per sandbox nodig?

Nee. Koppel langlevende branches alleen aan persistente omgevingen zoals integration, UAT en productie. Gebruik kortlevende feature branches voor scratch- en developer-orgs.

Welke sandbox hoort bij mijn UAT branch?

Een Partial Copy- of Full-sandbox, zodat businessusers tegen representatieve data testen in plaats van een lege developer-org.

Hoe wordt een wijziging tussen omgevingen gepromoveerd?

Via een beoordeelde merge van de ene branch naar de volgende, gevolgd door een deploy vanuit git naar de gekoppelde org. Promoveren is een merge, geen herdeploy vanuit een org.

Wat voorkomt dat een branch en zijn org uiteenlopen?

Source tracking plus deploy-vanuit-git. De branch blijft de bron van waarheid, en elke directe orgwijziging duikt op als een getrackte diff om te verzoenen.

Welk branchingmodel koppel ik eerst?

Kies het model voor de koppeling. Zie onze beslisregel om te kiezen op teamgrootte en sandbox-topologie.