Salesforce DevOps Playbook for Growing Mid Market Teams

The Mid-Market DevOps Problem

Your Salesforce org is too complex for change sets, but you don't have the budget or headcount for enterprise-grade DevOps tooling. You have 3-20 Salesforce developers, multiple sandboxes, and release cycles that are getting harder to manage as the team grows.

This is the mid-market DevOps problem. It's where most scaling Salesforce teams get stuck.

This playbook covers what actually works for teams at this size - based on patterns from dozens of mid-market Salesforce implementations.

The Right Org Strategy for Your Team Size

3-8 Developers

At this size, simplicity is your friend. You don't need 6 environments.

• Dev sandbox - each developer works in their own, OR a shared dev sandbox if org limits are tight
• QA sandbox - for testing before production
• Production

Deployment flow: Dev → QA → Production, automated by pipeline.

8-20 Developers

At this size, you need feature isolation to avoid developers blocking each other.

• Feature sandboxes (1 per active epic or developer pair)
• Integration sandbox - merges from all feature sandboxes
• UAT sandbox - for business sign-off
• Production

The integration sandbox is the key addition - it's where merge conflicts surface before they hit production.

Release Cadence: What Actually Works

Teams that ship on a fixed cadence ship more reliably than teams that ship "when ready." The cadence forces prioritization and prevents the accumulation of risk that causes production breaks.

• Weekly releases: Best for teams with active Salesforce development. Forces a weekly cutoff that keeps work small and rollback easy.
• Bi-weekly releases: Common at this team size. Matches typical sprint length. Long enough to complete meaningful work, short enough to limit risk.
• Monthly releases: Only works if your org is relatively stable. Every monthly release becomes high-stakes, which is stressful for the team and increases break risk.

Recommendation for 5-15 developer teams: bi-weekly releases on a fixed day (e.g., every other Wednesday). Set up the pipeline once, run it every sprint.

Roles That Need to Exist (Even on Small Teams)

You don't need full-time DevOps engineers. You need clear ownership.

• Release coordinator - owns the release calendar and go/no-go decisions. Can be a senior developer or technical lead. 2-3 hours per release cycle.
• Deployment reviewer - reviews what's going into each deployment, checks test coverage. Should be different from the person who wrote the code.
• Rollback owner - knows how to roll back every change in the release. With Serpent, this is a click - but someone needs to own the decision to use it.

The Metrics That Tell You Your DevOps Is Working

• Deployment frequency: How often do you successfully deploy to production? Target: at least once per sprint.
• Lead time for changes: From first commit to production. Target: under 2 weeks for standard changes.
• Change failure rate: % of deployments that cause a production incident. Target: under 5%.
• Mean time to restore: How long from production break to fix deployed. Target: under 4 hours.

These are the four DORA metrics. Measure them monthly. If deployment frequency is going down or failure rate is going up, your process has a bottleneck that needs fixing before it gets worse.

Common Mistakes at This Team Size

• Skipping UAT on "small" changes. Production breaks almost always come from changes that seemed too small to need UAT.
• Letting the integration sandbox get stale. If it's more than 2 weeks behind production, it's not useful. Refresh it on a schedule.
• Treating releases as heroics. If every release requires someone staying late, your process is broken, not your team.
• No documentation of what's in each release. Release notes don't need to be formal - a Slack message with 5 bullet points is enough. Do it every time.

FAQ

How many sandboxes does a mid-market Salesforce team need?

With 3 to 8 developers, a dev sandbox, a QA sandbox and production are enough. Past 8 developers, add feature sandboxes, an integration sandbox where merge conflicts surface, and a UAT sandbox for business sign-off.

What release cadence works best for a growing Salesforce team?

A fixed cadence beats shipping "when ready", because it forces prioritisation and stops risk accumulating. Bi-weekly on a set day suits most teams at this size, weekly suits very active development, and monthly only works if the org is stable.

Do you need a dedicated DevOps engineer for Salesforce?

Not at this size. What you need is clear ownership: a release coordinator for the calendar and go/no-go call, a deployment reviewer who did not write the code, and someone who owns the decision to roll back.

Which metrics show your Salesforce DevOps is working?

The four DORA metrics: deployment frequency, lead time for changes, change failure rate and mean time to restore. Measure them monthly, and treat falling deployment frequency or a rising failure rate as a bottleneck to fix early.

Making the Tooling Decision

At the 50-200 person company size with 5-20 Salesforce developers, you need a tool that's:

• Fast to set up - you can't spend 6 months on implementation
• Not per-user priced - your team is growing and you don't want cost surprises
• Opinionated enough to handle your sandboxes - not a blank canvas that requires you to build the pipeline from scratch

Serpent is built specifically for this team size. See pricing or try it free.