Andrew Hanna

Andrew Hanna

Zo bepaal je de omvang van een Salesforce DevOps-uitrol voor een team van 10

Zo bepaal je de omvang van een Salesforce DevOps-uitrol voor een team van 10

Het korte antwoord: bepaal de omvang van een Salesforce DevOps-uitrol voor een team van 10 op basis van het werk, niet van het aantal mensen. Tel wie metadata wijzigt, hoeveel wijzigingen parallel lopen en hoe vaak je released. Plan daarna één kortlevende omgeving per wijziging, één gedeelde UAT-sandbox, drie parttime eigenaren en een gefaseerde uitrol. De meeste teams van 10 hebben geen aparte DevOps-engineer nodig.

Wat betekent het eigenlijk om een Salesforce DevOps-uitrol te dimensioneren?

Dimensioneren betekent bepalen hoeveel je van vier dingen nodig hebt voordat je iets koopt of bouwt:

  • Toegang: wie een plek in de tool nodig heeft.
  • Omgevingen: door hoeveel orgs de pipeline loopt.
  • Volume: hoeveel deployments en releases per maand.
  • Eigenaarschap: wie de pipeline gezond houdt.

De meeste gidsen springen direct naar de toolkeuze. Zet deze vier eerst goed, dan kiest de shortlist zich grotendeels vanzelf.

Hoeveel mensen in een team van 10 hebben toegang nodig?

Meestal allemaal, om verschillende redenen. Een typisch team van tien bestaat uit admins, developers, een business analist en iemand die test of goedkeurt. Admins en developers maken wijzigingen, de analist koppelt werk aan tickets en goedkeurders moeten zien wat er richting productie gaat.

Hier telt het prijsmodel. Bij prijzen per gebruiker is elke plek een beslissing. Zo vermeldt de gepubliceerde prijslijst van Gearset het Teams-abonnement voor $320 per gebruiker per maand voor de kernfuncties, met automatisering apart geprijsd per team. Dat model dwingt je te vragen wie echt een plek nodig heeft, en wie buiten de boot valt, werkt buiten het proces. Een prijs per bedrijf haalt die afweging weg.

Hoeveel omgevingen heeft een team van 10 nodig?

Minder langlevende sandboxes dan je denkt, en meer kortlevende orgs.

  1. Eén omgeving per wijziging. Een scratch org of developer-sandbox voor elk work item, zodat wijzigingen niet botsen. De scratch org-toewijzingen van Salesforce geven een Dev Hub op Enterprise Edition 40 actieve en 80 dagelijkse scratch orgs, ruim genoeg voor tien mensen.
  2. Eén gedeelde integratie- of UAT-sandbox. Waar wijzigingen samenkomen en business-gebruikers goedkeuren. Een Partial Copy volstaat voor de meeste teams.
  3. Een Full-sandbox, als je contract er een bevat, voor de laatste regressie- en performancechecks op productie-achtige data.
  4. Productie. Ontvangt alleen deployments, nooit directe aanpassingen.

Het aantal sandboxes hangt af van je Salesforce-editie en contract, dus controleer dat voordat je de pipeline ontwerpt. Zodra je meer dan één langlevende sandbox hebt, plan je hoe fixes terugstromen, zoals beschreven in back-promotion opzetten in een Salesforce DevOps-pipeline.

Wie moet eigenaar zijn van de pipeline in een team van 10?

Wijs eigenaren aan in plaats van een team aan te nemen. Drie parttime rollen dekken het:

  • Release-eigenaar: bepaalt wat er live gaat en wanneer.
  • Reviewer: keurt wijzigingen goed vóór de merge. Laat dit rouleren, zodat review nooit wacht op de agenda van één persoon.
  • Pipeline-eigenaar: houdt omgevingen, rechten en checks werkend. Een paar uur per week, geen fulltime baan.

Als maar één persoon kan releasen, dan is die persoon je releaseritme. Zet minstens twee mensen achter elke rol.

Op hoeveel pipelinevolume moet je rekenen?

Schat het in vanuit je backlog, niet vanuit een leveranciersniveau. Een uitgewerkt voorbeeld voor een team van tien:

  • 40 tickets per maand, elk één keer naar een eigen omgeving gedeployd: 40 deployments.
  • Wekelijkse releases naar productie: ongeveer 4 releases.
  • AI-review op elke wijziging.

Vertaal dat naar wat jouw tool meet. In het creditmodel van Serpent kost een feature-deployment 1 credit, een productierelease 2 en een AI-actie 1 extra, dus dit voorbeeld komt uit op ongeveer 90 credits per maand: boven de 30 die in het gratis Essentials-abonnement zitten, ruim binnen de 300 van Scale. Reken je eigen cijfers door op de prijspagina voordat je beslist.

Hoe ziet een gefaseerde uitrol eruit?

  1. Nulmeting. Leg vast hoe lang een wijziging duurt van goedgekeurd tot live, en hoeveel problemen productie bereiken.
  2. Koppelen en piloot. Zet productie en één sandbox onder versiebeheer en laat een kleine groep twee of drie echte tickets doorlopen.
  3. Voeg de poorten toe. Zet geautomatiseerde tests, statische analyse en review aan voor elke wijziging. De 5 pijlers van Salesforce DevOps werken als checklist voor wat die poorten moeten afdekken.
  4. Haal iedereen erbij. Breng de overige admins en developers over en stop met change sets voor alles wat de pipeline nu afhandelt.
  5. Meten en bijsturen. Vergelijk na een paar releasecycli met de nulmeting voordat je omgevingen of tooling toevoegt.

Welke tool past bij een team van 10?

Eerst dimensioneren, dan een shortlist maken. Het eigen DevOps Center van Salesforce installeer je zonder extra kosten in orgs met Professional (met API-toegang), Enterprise en Unlimited Edition. Gearset, Copado, AutoRABIT, Flosum, Blue Canvas en Salto passen elk bij andere teamvormen en budgetten, en onze vergelijking van de beste Salesforce DevOps-tools voor 2026 bespreekt ze platform voor platform. Beoordeel elke optie op de vier dimensioneringsvragen: wie ermee kan werken, hoe ze met omgevingen omgaat, wat volume kost en hoeveel eigenaarschap ze vraagt.

FAQ

Heeft een Salesforce-team van 10 een aparte DevOps-engineer nodig?

Meestal niet. Aangewezen parttime eigenaren voor release, review en de gezondheid van de pipeline dekken de meeste teams van deze omvang.

Hoeveel sandboxes heeft een team van 10 nodig?

Meestal één gedeelde integratie- of UAT-sandbox plus een kortlevende org per wijziging, en een Full-sandbox voor de laatste regressie als je contract er een bevat.

Hoe lang moet de uitrol duren?

Lang genoeg om een piloot en een paar releasecycli te draaien voordat je opschaalt. Faseer het in plaats van iedereen tegelijk over te zetten.

Horen admins bij de uitrol?

Ja. Admins maken in de meeste Salesforce-teams veel van de wijzigingen, en een pipeline die zij niet kunnen gebruiken laat dat werk erbuiten.

Serpent rekent per bedrijf met onbeperkt aantal gebruikers, zodat alle tien mensen vanaf dag één in de pipeline kunnen werken. Begin gratis met Essentials, stap over naar Scale als het volume groeit, en vind meer stapsgewijze gidsen in de SF Guides-bibliotheek.

Gerelateerde artikelen

Benieuwd naar sneller releasen voordat je instapt? Laten we praten

Vrijblijvend.