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.

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.