CI/CD pipelines for teams of 5–50
A reference architecture, plus the trade-offs that matter as you scale past each team-size threshold.
CI/CD pipeline design is not a one-size-fits-all problem. The right architecture for a 5-person team shipping a monolith is different from the right architecture for a 50-person team shipping 12 microservices. The mistake most teams make is copying the pipeline architecture of a company 10× their size, then maintaining infrastructure complexity that does not match their actual needs.
The 5–15 person reference architecture
At this team size, simplicity is the priority. A single repository, a single pipeline, and a deployment target that the whole team understands. GitHub Actions or GitLab CI with a linear: test → build → deploy to staging → deploy to production. Manual approval gates for production are fine at this scale. The risk of over-engineering is higher than the risk of under-engineering.
- Single pipeline, linear stages
- Automated test on every PR — unit + integration
- Staging environment for every main branch merge
- Manual approval gate for production deployment
- Deployment takes < 10 minutes end-to-end
The 15–50 person threshold
At this size, the monolith pipeline starts to slow the team: too many unrelated test failures blocking deployment, shared environments causing conflicts, deployment time stretching past 20 minutes. The right response is not microservices — it is better pipeline design. Per-service pipelines, parallel test execution, ephemeral preview environments, and automated deployment to staging with human gate only for production.
- Per-service or per-domain pipelines with independent deployment
- Parallel test execution — integration tests should not block unit test feedback
- Ephemeral preview environments per pull request
- Feature flags for progressive rollout — not all-or-nothing production deploys
- Observability from deployment: deployment markers in Datadog/Grafana to correlate deploys with incidents
The trade-offs that actually matter
Speed vs reliability is the perennial trade-off. Faster pipelines mean faster feedback and less context-switching. Reliable pipelines mean fewer false failures and more trust in the green signal. The right balance: test fast (< 5 min for unit), test thoroughly (integration tests in parallel), and make the pipeline signal trustworthy — a passing pipeline should mean something deployable.
A CI/CD pipeline the team does not trust is worse than no pipeline at all. Green must mean green.
Common mistakes at each threshold
- 5–15 person: Over-engineering the pipeline before the codebase warrants it
- 15–50 person: Moving to microservices to fix a pipeline problem (wrong layer)
- 50+ person: Not investing in platform engineering to standardize pipeline patterns across teams
Application Modernization
Migrate legacy systems to modern, cloud-native architectures without disrupting the business.
Start a conversation
Let's find where value is leaking in your ecosystem.
Bring us the workflow, the channel, or the half-built thing that's stuck. In 30 minutes we'll tell you plainly which parts should connect, where intelligence pays back — and what it takes to ship.