Git-branchingstrategieen voor Salesforce-teams: een beslisregel

Kort gezegd: kies je branchingmodel op twee inputs, teamgrootte en sandbox-topologie, en verder niets. Onder ongeveer vier bijdragers met alleen developer-sandboxes: een main-branch en kortlevende feature branches. Tussen vier en tien met een partial copy voor UAT: voeg een release branch per release toe en stop daar. Daarboven, of met een full sandbox en een vast changevenster, verdient GitFlow zijn ceremonie. Branch per omgeving is een compliancekeuze, geen engineeringkeuze.

Wat bepaalt een branchingstrategie eigenlijk?

Drie dingen, en alleen drie: waar werk in uitvoering leeft, hoe een wijziging naar de volgende omgeving wordt gepromoveerd, en wat waar moet zijn voordat iets productie bereikt. De rest is diagramversiering.

Salesforce-teams gaan hier de mist in omdat het algemene engineeringadvies iets aanneemt dat op het platform niet klopt: dat een branch je ook een plek geeft om hem te draaien.

Wat zijn de drie modellen in gewone taal?

Trunk-based met kortlevende feature branches

Een langlevende branch, main, die altijd weerspiegelt wat productie zou moeten zijn. Feature branches leven dagen, geen weken, en mergen terug via een pull request. De minste bewegende delen, de minste conflicten, de zwaarste discipline.

GitFlow

main voor uitgebrachte code, develop voor geintegreerd werk, plus release- en hotfixbranches. Gebouwd voor geplande releases en voor het onderhouden van een live versie terwijl de volgende wordt gebouwd. Het kost een extra permanente branch en veel mergewerk.

Branch per omgeving

Een branch die elke org spiegelt: dev, UAT, staging, productie. Meestal het eerste wat teams bouwen, omdat het lijkt op het orglandschap dat ze al hebben. Promoveren wordt een merge tussen omgevingsbranches, wat netjes klinkt en uitmondt in merges van merges plus routinematig cherry-picken.

Welke Salesforce-beperkingen slopen het standaardadvies?

Hier stoppen de meeste branchingartikelen, en hier zit de echte beslissing.

• Een branch geeft je geen org. Omgevingen zijn schaars en traag. Salesforce hanteert minimale refreshintervallen van een dag voor Developer en Developer Pro, vijf dagen voor Partial Copy en 29 dagen voor Full. Het aantal langlevende branches dat je echt kunt testen wordt begrensd door je sandboxaantal, niet door je Git-vaardigheid.
• Metadata wordt opgehaald, niet geschreven. Admins wijzigen dingen in een org en iemand pullt het later. Een langlevende branch is niet te verzoenen met declaratief werk dat nooit in Git terechtkwam.
• Sommige dingen hebben helemaal geen branch. Org-brede instellingen, licenties, bepaalde configuratie en alle recorddata leven buiten de repo. Een model dat aanneemt dat elk omgevingsverschil in Git zit, liegt stilletjes tegen je.
• Er zijn geen feature flags voor clicks. Trunk-based in gewone engineering leunt op toggles om onaf werk te mergen. Declaratieve configuratie heeft vaak geen toggle, dus het Salesforce-equivalent is de metadata deployen en de permission set-toewijzing achterhouden tot go-live.
• Mergekosten zijn asymmetrisch. Profiles, permission sets en layouts conflicteren veel erger dan Apex. Elke extra week dat een branch leeft vermenigvuldigt die kosten, wat Salesforce harder richting korte branches duwt dan gewone software.

Wat is dan de beslisregel?

1. Een tot drie bijdragers, alleen developer-sandboxes, geen vaste releasedatum. Main plus kortlevende feature branches. Meer is ceremonie die je in maand drie loslaat.
2. Vier tot tien bijdragers, een partial copy voor UAT, elke sprint releasen. Main, kortlevende feature branches en een release branch per release. Weersta een permanente develop; je sandboxaantal rechtvaardigt hem niet.
3. Meer dan tien bijdragers, of een full sandbox, of een vast changevenster, of je moet de live release patchen terwijl de volgende wordt gebouwd. GitFlow. Nu koopt de ceremonie iets echts.
4. Package- en ISV-teams. Branch per packageversie, niet per omgeving. Je release-eenheid is de packageversie en je testbed is een scratch org, dus omgevingsbranches modelleren het verkeerde ding.
5. Branch per omgeving. Gerechtvaardigd als een branch een auditeerbare spiegel van een org moet zijn, wat een regelgevingseis is en geen leveringsvoorkeur. Ga erin met de kosten voor ogen: cherry-picken wordt routine en drift wordt onzichtbaar.

Merk op dat releasecadans nauwelijks voorkomt. Cadans is een uitkomst van je sandbox-topologie, geen zelfstandige input, en teams die kiezen op gewenste cadans krijgen een proces dat hun omgevingen niet kunnen dragen.

Hoe stap je af van branch per omgeving zonder big bang?

1. Maak vandaag geen nieuwe omgevingsbranches meer. Het model stopt met groeien voordat het begint te krimpen.
2. Verzoen main met productie en behandel het verschil als echte backlog, niet als curiositeit. Daar zitten meestal de verrassingen.
3. Maak van omgevingsbranches deploymentdoelen in de pijplijn in plaats van Git-branches. De omgeving blijft bestaan, ze is alleen geen plek meer waar code woont.
4. Begrens de leeftijd van feature branches op een sprint. Langer vraagt om een packagegrens of een permissiepoort, niet om een langere branch.
5. Houd precies een release branch, en alleen als je echt een live release ondersteunt terwijl je de volgende bouwt.

Het model laten beklijven

Het model dat contact met een echt team overleeft, is het model dat de pijplijn afdwingt, niet het model in het onboardingdocument. Als een consultant de branchingregels moet onthouden, worden ze in de eerste drukke releaseweek gebroken. Serpent draait een ticketgestuurde workflow met Git op de achtergrond, zodat de branch, de pull request en het promotiepad uit het ticket komen in plaats van uit het geheugen. Meer pijplijngidsen staan in onze SF Guides-bibliotheek.

FAQ

Is trunk-based realistisch voor een team van admins?

Ja, en het is meestal makkelijker dan GitFlow, want er is een branch om te begrijpen. De discipline die telt is korte branches, niet Git-vaardigheid.

Hebben we een Git-branch per sandbox nodig?

Nee. Een sandbox is een deploymentdoel. Een branch per org koppelen is de hoofdoorzaak van merges van merges en permanent cherry-picken.

Hoe lang mag een Salesforce feature branch leven?

Dagen. Een sprint is de bovengrens. Daarna kosten metadatadrift en profielconflicten meer dan de branch oplevert.

Hoe werken hotfixes bij trunk-based?

Branch vanaf de laatst uitgebrachte commit, fix, valideer, deploy, en merge direct terug naar main zodat de fix bij de volgende release niet verdwijnt.

Verandert het model voor 2GP-packageteams?

Ja. Branch per packageversie en test in scratch orgs. Omgevingsbranches modelleren een orglandschap waar een packageteam niet naartoe releaset.