Small teams do not fail at CI/CD because the tooling is hard. They fail because they build a pipeline sized for an organisation four times larger, and then nobody has time to keep it running.
The goal for a team of two to six engineers is narrower than it sounds: every change goes to production the same way, every time, and any engineer can explain that way in a minute.
What the pipeline must do
Four things, in order:
- Verify. Run the tests and type checks that would embarrass you if they failed in production.
- Build once. Produce a single artefact — usually a container image — tagged with the commit.
- Deploy that artefact. The same bytes go to staging and then production. Never rebuild per environment.
- Prove it worked. A health check, a smoke test, and an obvious way to roll back.
Anything beyond this is optimisation. Get these four solid before adding a fifth.
Build once, promote the artefact
Rebuilding per environment is the most common structural mistake. If staging builds from main and production builds from a tag, you have tested one thing and shipped another. Dependency resolution alone can make them differ.
Build the image once on merge, push it to a registry with an immutable tag, and let each environment deploy that tag. Promotion becomes a change to one value rather than a new build.
Keep secrets out of the repository
Use your CI provider's secret store or a managed secrets service, injected at deploy time. Two rules that prevent most incidents:
- No secret in a repository, ever — including in a
.env.examplethat someone helpfully filled in. - Different credentials per environment, so a staging leak is not a production incident.
Rotate anything that has ever appeared in a build log.
Make the pipeline fast enough to trust
A pipeline that takes twenty-five minutes stops being a safety net and becomes an obstacle to work around. Aim to have the verify stage finish in under five minutes:
- Cache dependencies properly, and check the cache is actually hitting.
- Run independent jobs in parallel.
- Keep the slowest end-to-end tests on a separate, less frequent schedule.
If tests are flaky, fix or delete them. A test people routinely re-run until it passes is worse than no test, because it trains the team to ignore red.
Deploy in a way you can undo
For most small-team workloads, a rolling deployment with health checks is sufficient. Blue-green and canary releases are genuinely useful, but they add infrastructure and cost that a small team should adopt only when the risk justifies it.
What matters far more is that rollback is a single documented command that someone has run recently. An untested rollback path is a plan, not a capability.
Infrastructure as code, in the same pipeline
Once application deployment is reliable, bring the infrastructure into the same discipline. Terraform or Bicep, in version control, with a plan on pull request and an apply on merge. The plan output in the PR is the part that pays for itself: reviewers can see that a change destroys a database before it does.
State needs a remote backend with locking from day one. Local state files are how two engineers accidentally overwrite each other's infrastructure.
What to skip for now
- A full internal developer platform.
- A service mesh, unless you have a specific problem it solves.
- Kubernetes, if a managed container service or a couple of well-configured VMs would do. Kubernetes is excellent and it is also a system that must be maintained.
The honest test
Ask a new engineer to ship a one-line copy change on their second day. If they can do it without a walkthrough, and without anyone holding their breath, the pipeline is working.
If yours does not pass that test, we can help you get there — usually in weeks, not quarters, and built in your repositories so your team owns it afterwards. Book a 30-minute call and tell us where it currently hurts.