CI/CD Best Practices · DevOps for Growing Teams

CI/CD Pipeline for a 10-Person Engineering Team: A Practical Blueprint

What to build, what to skip, and how to keep the pipeline from becoming a part-time job for your best engineer.

By Subeesh Sivanandan, Founder & CEO, Stonetusker Systems · Updated October 2026 · Est. reading time: 11 minutes

Why 10 engineers is an awkward size for CI/CD

With three engineers, someone can deploy by hand and nobody gets hurt. With thirty, you probably have a platform team whose whole job is the pipeline. At ten you sit in the gap: too many people to coordinate informally, too few to dedicate anyone full time.

So the pipeline becomes everybody's problem and therefore nobody's. We keep finding the same picture. A Jenkins server that one engineer understands. Workflow files copied across eight repositories, each slightly different. A test suite that goes red twice a week for no reason, so people hit "re-run" until it goes green.

None of this is a tooling failure. It's an ownership failure, and the fix is a deliberately small design that one person can hold in their head, plus a rotation so more than one person can.

The shape of the pipeline

Keep it linear and boring. Every change goes through the same stages, in the same order, for every service. Exceptions are where small teams lose weeks.

The one rule that matters most here: build once. If your staging deploy and your production deploy each compile the code separately, you aren't testing what you ship. Different dependency resolution, a different base image tag that moved overnight, a build flag set in one place and not the other. All of these turn into incidents that nobody can reproduce.

Version the artifact with the commit SHA and promote it through environments. Configuration changes per environment. The artifact never does.

Choosing tooling without overbuilding

For most ten-person teams the answer is hosted CI from wherever the code already lives. GitHub Actions if you're on GitHub, GitLab CI if you're on GitLab. You get runners, caching, secrets storage and pull request integration without running a single server. The GitHub Actions documentation covers reusable workflows, which is the feature that will save you the most copy-paste.

Self-hosted runners earn their place in a few cases: you need access to hardware (embedded targets, GPUs), you have builds so heavy that hosted minutes get expensive, or your network rules keep the build away from internal systems. Even then, run the runners, not the CI brain.

What about Jenkins?

If you already run Jenkins and someone genuinely owns it, with plugins pinned and config in version control, keep it and move on to problems that cost you more. Starting a new Jenkins installation in 2026 for a team this size is hard to justify.

Three small decisions that pay off early

• Put shared steps (build, test, scan, deploy) into reusable workflows or templates, so a fix lands in every repo at once.
• Authenticate to your cloud with short-lived OIDC credentials instead of long-lived access keys stored as secrets.
• Describe environments in code (Terraform, Pulumi, whatever you already use) so staging is a copy of production and not a cousin.

Branching and merge rules

Trunk-based development fits a team this size. Branches live for a day or two, merge to main behind feature flags, and main is always releasable. The trunkbaseddevelopment.com site is a decent reference if your team needs convincing.

Long-lived release branches look safe and aren't. Every one of them needs its own pipeline runs, its own cherry-picks and its own bug fixes, and with ten people you can't afford the multiplication.

Protect main with the minimum that works. Required status checks, one reviewer, no direct pushes. Resist the urge to add a second reviewer, a changelog bot and a mandatory ticket link in the first month. Add rules when you can name the incident they would have prevented.

Test speed and flaky tests

Developers will tolerate a pipeline that takes eight minutes. At twenty minutes they start batching changes into larger pull requests, which are harder to review and riskier to ship. The pipeline shapes behavior whether you intend it to or not.

Split tests by speed. Unit tests and a thin layer of contract checks run on every pull request. Slower integration and end-to-end suites run on the main build, or on a schedule if they're very slow. Cache dependencies, run test shards in parallel, and look at the slowest ten tests every quarter, because there's almost always one that spins up a whole database to check a string formatter.

Flaky tests need an owner

A flaky test is worse than no test. It teaches the team that red doesn't mean anything. When a test fails, then passes on re-run with no code change, quarantine it the same day: move it out of the blocking path, open a ticket, and give it a named owner with a deadline. Count how many tests are quarantined. If that number only grows, the problem is process, not the tests.

Deployment and rollback

Deploys should be dull. Merge, wait, done. Whether production deploys happen fully automatically or behind a single approval click depends on your risk appetite, and both are fine. Many teams start with the approval click and drop it after a few months of clean deploys.

Rollback is where most small teams are quietly exposed. The cleanest model is that rollback means redeploying the previous known-good artifact, using the same pipeline and the same button. If rollback is a different, rarely used procedure, it will fail the one time you need it.

Database changes complicate this. Use the expand and contract pattern: add the new column or table first, deploy code that works with both shapes, and only remove the old structure in a later release. A migration that can't be undone turns every rollback into a data decision.

Add a post-deploy gate that watches error rate and latency for a few minutes and rolls back automatically on a clear regression. You don't need canary analysis or a service mesh for this. A health check and a threshold on a metric you already collect gets you most of the benefit. Progressive delivery can come later, if traffic and risk justify it.

A six-step rollout playbook

If your current setup is manual or half-automated, don't rebuild everything at once. This order delivers value early and keeps the team shipping while you change the plumbing.

1. Measure where you arePick one service and record how long it takes from merge to production today, how often deploys fail, and how long recovery takes. Rough numbers from the last month are enough.
2. Get pull request checks under 10 minutesAdd caching, parallelize tests and move slow suites off the blocking path. Developers feel this change within a day.
3. Build the artifact onceProduce a single versioned artifact or container image per commit on main, push it to a registry, and make every later stage consume that artifact instead of rebuilding.
4. Automate staging and production deploysDeploy to staging on every main build, run smoke tests, then promote to production automatically or behind one approval. Retire the manual deploy runbook once this works.
5. Add rollback and verificationMake rollback a redeploy of the previous artifact, add a post-deploy health and error-rate check, and rehearse a rollback in staging with the whole team watching.
6. Review the four DORA metrics monthlyTrack deployment frequency, lead time for changes, change failure rate and time to restore service. Spend 30 minutes a month on the trend and pick one thing to improve.

Roll one service through all six steps before touching the rest. The first service teaches you which parts of your shared templates are wrong, and that is much cheaper to learn once than eight times.

Anti-patterns we see most often

Metrics worth tracking

The DORA research program identified four measures that correlate with software delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service. The DORA site has the definitions and the latest research.

For a ten-person team, don't chase benchmark numbers from a report. Chase your own trend. If lead time is dropping and change failure rate isn't climbing, the pipeline is doing its job. If deployment frequency goes up while failure rate also goes up, you've made it easier to ship broken code, and the test layer needs attention.

Pull these numbers from the pipeline itself where possible. Spreadsheets maintained by hand die within two months.

Compliance and audit evidence

If you're heading toward SOC 2, or already there, a clean pipeline helps more than almost any other investment. Auditors asking about change management want to see that changes are reviewed, tested and traceable. Branch protection rules, required checks, and a deploy history tied to commits are that evidence, generated automatically and without a screenshot-gathering sprint before the audit.

Supply chain integrity is the other angle. The SLSA framework gives a practical ladder for build provenance, from scripted builds to signed, tamper-resistant ones. You don't need the top level on day one. Producing a signed, versioned artifact from a controlled build is a reasonable first rung.

• CI/CD pipeline design
• Trunk-based development
• Build once, promote
• GitHub Actions
• Flaky test management
• Automated rollback
• DORA metrics
• Reusable workflows
• SOC 2 change management
• SLSA

Frequently asked questions

Related reading: Stonetusker CI/CD and release engineering services · Stonetusker DevOps and platform engineering