Salesforce DevOps-playbook voor groeiende mid-marketteams

Het mid-market DevOps-probleem

Je Salesforce-org is te complex voor change sets, maar je hebt niet het budget of de personeelsbezetting voor enterprise-grade DevOps-tooling. Je hebt 3-20 Salesforce-developers, meerdere sandboxes, en releasecycli die steeds lastiger te beheren worden naarmate het team groeit.

Dit is het mid-market DevOps-probleem. Hier lopen de meeste schalende Salesforce-teams vast.

Dit playbook behandelt wat echt werkt voor teams van deze omvang - gebaseerd op patronen uit tientallen mid-market Salesforce-implementaties.

De juiste org-strategie voor jouw teamgrootte

3-8 developers

Op deze schaal is eenvoud je vriend. Je hebt geen 6 omgevingen nodig.

• Dev sandbox - elke developer werkt in zijn eigen sandbox, OF een gedeelde dev-sandbox als org-limieten krap zijn
• QA sandbox - voor testen voor productie
• Productie

Deploymentflow: Dev → QA → Productie, geautomatiseerd via pipeline.

8-20 developers

Op deze schaal heb je feature-isolatie nodig om te voorkomen dat developers elkaar blokkeren.

• Feature sandboxes (1 per actieve epic of developerpaar)
• Integratiesandbox - merget vanuit alle feature sandboxes
• UAT-sandbox - voor business-goedkeuring
• Productie

De integratiesandbox is de belangrijkste toevoeging - het is waar merge conflicts naar boven komen voordat ze productie raken.

Releaseritme: wat echt werkt

Teams die op een vast ritme shippen, shippen betrouwbaarder dan teams die shippen "wanneer het klaar is". Het ritme forceert prioritering en voorkomt de opbouw van risico die productie-uitval veroorzaakt.

• Wekelijkse releases: Het beste voor teams met actieve Salesforce-ontwikkeling. Forceert een wekelijkse afsluiting die werk klein houdt en rollback eenvoudig.
• Tweewekelijkse releases: Gebruikelijk bij deze teamgrootte. Past bij de typische sprintlengte. Lang genoeg om betekenisvol werk af te ronden, kort genoeg om risico te beperken.
• Maandelijkse releases: Werkt alleen als je org relatief stabiel is. Elke maandelijkse release wordt hoogrisico, wat stressvol is voor het team en het uitvalrisico verhoogt.

Aanbeveling voor teams van 5-15 developers: tweewekelijkse releases op een vaste dag (bijv. elke andere woensdag). Zet de pipeline eenmalig op, draai hem elke sprint.

Rollen die moeten bestaan (zelfs bij kleine teams)

Je hebt geen fulltime DevOps-engineers nodig. Je hebt duidelijke eigenaarschap nodig.

• Releasecoordinator - bezit de releasekalender en go/no-go-beslissingen. Kan een senior developer of technisch lead zijn. 2-3 uur per releasecyclus.
• Deploymentreviewer - beoordeelt wat er in elke deployment gaat, controleert testdekking. Moet iemand anders zijn dan wie de code schreef.
• Rollback-eigenaar - weet hoe elke wijziging in de release terug te draaien. Met Serpent is dit een klik - maar iemand moet de beslissing bezitten om het te gebruiken.

De metrics die vertellen of je DevOps werkt

• Deploymentfrequentie: Hoe vaak deploy je succesvol naar productie? Doel: minstens eenmaal per sprint.
• Doorlooptijd voor wijzigingen: Van eerste commit tot productie. Doel: onder de 2 weken voor standaardwijzigingen.
• Wijzigingsfoutpercentage: % deployments dat een productie-incident veroorzaakt. Doel: onder de 5%.
• Gemiddelde hersteltijd: Hoe lang van productie-uitval tot gedeployde fix. Doel: onder de 4 uur.

Dit zijn de vier DORA-metrics. Meet ze maandelijks. Als de deploymentfrequentie daalt of het foutpercentage stijgt, heeft je proces een bottleneck die je moet oplossen voordat het erger wordt.

Veelgemaakte fouten bij deze teamgrootte

• UAT overslaan bij "kleine" wijzigingen. Productie-uitval komt bijna altijd voort uit wijzigingen die te klein leken om UAT nodig te hebben.
• De integratiesandbox verouderd laten raken. Als hij meer dan 2 weken achterloopt op productie, is hij niet nuttig meer. Ververs hem volgens een schema.
• Releases als heldendaden behandelen. Als elke release betekent dat iemand moet overwerken, is je proces kapot, niet je team.
• Geen documentatie van wat in elke release zit. Releasenotities hoeven niet formeel te zijn - een Slack-bericht met 5 bulletpoints is genoeg. Doe het elke keer.

FAQ

Hoeveel sandboxes heeft een mid-market Salesforce-team nodig?

Met 3 tot 8 developers zijn een dev-sandbox, een QA-sandbox en productie genoeg. Boven de 8 developers voeg je feature sandboxes toe, een integratiesandbox waar merge conflicts naar boven komen, en een UAT-sandbox voor business-goedkeuring.

Welk releaseritme werkt het best voor een groeiend Salesforce-team?

Een vast ritme verslaat shippen "wanneer het klaar is", omdat het prioritering forceert en risico-opbouw stopt. Tweewekelijks op een vaste dag past bij de meeste teams van deze omvang, wekelijks past bij zeer actieve ontwikkeling, en maandelijks werkt alleen als de org stabiel is.

Heb je een toegewijde DevOps-engineer nodig voor Salesforce?

Niet op deze schaal. Wat je nodig hebt is duidelijk eigenaarschap: een releasecoordinator voor de kalender en de go/no-go-beslissing, een deploymentreviewer die de code niet schreef, en iemand die de beslissing bezit om terug te draaien.

Welke metrics laten zien dat je Salesforce DevOps werkt?

De vier DORA-metrics: deploymentfrequentie, doorlooptijd voor wijzigingen, wijzigingsfoutpercentage en gemiddelde hersteltijd. Meet ze maandelijks, en behandel een dalende deploymentfrequentie of een stijgend foutpercentage als een bottleneck om vroeg op te lossen.

De toolingbeslissing maken

Bij een bedrijf van 50-200 mensen met 5-20 Salesforce-developers heb je een tool nodig die:

• Snel op te zetten is - je kunt geen 6 maanden aan implementatie besteden
• Niet per gebruiker geprijsd is - je team groeit en je wilt geen kostenverrassingen
• Genoeg opgevat is om je sandboxes aan te kunnen - geen blanco canvas dat je verplicht de pipeline vanaf nul te bouwen

Serpent is specifiek gebouwd voor deze teamgrootte. Bekijk pricing of probeer het gratis.