Continuous integration and delivery guidance is mostly written for organisations with platform teams. A team of five needs a different set of priorities: fast feedback, few moving parts, and nothing that requires a specialist to maintain.
Speed is the feature
Pipeline duration determines whether the pipeline helps or hinders. Under ten minutes and engineers wait for the result. Over twenty and they context-switch, which costs more than the pipeline saves.
Four things get you there.
Cache dependencies properly. Reinstalling packages on every run is usually the largest single cost and the easiest to fix.
Run independent jobs in parallel. Lint, unit tests and build do not depend on each other.
Split the test suite by duration. Fast unit tests on every push; slower integration and end-to-end tests on merge to main or on a schedule.
Only build what changed. In a monorepo, path filtering avoids rebuilding everything for a documentation edit.
Flaky tests are an emergency
A test that fails randomly destroys trust in the whole pipeline. Once engineers habitually re-run failed builds, the pipeline has stopped being a safety net and become a toll booth.
Treat flakiness as a priority bug, not a nuisance. Quarantine the test immediately so it does not block anyone, open a ticket with an owner, and fix or delete it within a defined window. A quarantine list that grows without being worked is just a slower way of deleting your test suite.
Common causes, in rough order: timing assumptions and sleeps, shared state between tests, dependence on external services, and ordering dependencies. Running tests in random order surfaces the last two quickly.
Branching: keep it short-lived
Long-lived feature branches are the main source of painful merges and integration bugs. Trunk-based development — short branches merged to main within a day or two, behind feature flags where necessary — avoids most of it.
For a small team, elaborate branching models like GitFlow add ceremony without benefit. Main is always deployable, branches are short, and releases are tags or deployments rather than separate long-lived branches.
Feature flags are what make this work for incomplete features. They also bring their own debt: every flag is a branch in the code that someone must eventually remove. Keep a list and delete them after rollout.
What belongs in the pipeline
A reasonable minimum for a small team, in order of execution:
- Lint and format check — seconds, catches trivia before a human looks.
- Type check, if the language has one.
- Unit tests — the bulk of coverage, fast.
- Build the artefact once, and deploy that same artefact to every environment. Rebuilding per environment means you never tested what you shipped.
- Dependency vulnerability scan and secret scanning.
- Integration tests against real dependencies in a disposable environment.
- Deploy to staging automatically.
- A small set of smoke tests against staging.
- Deploy to production, automatically or with one approval.
Deployment safety
Deploying frequently is only safe if a bad deployment is cheap to undo.
Make rollback a single action. Tested regularly, not theorised about. If rollback requires a database migration to be reversed by hand, you do not have rollback.
Make migrations backwards compatible. Expand, migrate, contract: add the new column, deploy code that writes both, backfill, deploy code that reads the new one, remove the old. Slower, and it means any deployment can be reverted without data loss.
Roll out progressively. Even a crude version — deploy to one instance, watch for five minutes, continue — catches a large share of bad releases before they reach everyone.
Watch the right signals after deploy. Error rate and latency, automatically, with an alert. See observability versus monitoring.
Secrets and credentials
The pipeline has access to production, which makes it a high-value target.
Use short-lived credentials issued per run rather than stored long-lived keys — most CI systems now support federated identity with the major cloud providers. Scope permissions to exactly what the job needs. Never expose secrets to pull requests from forks. And scan for committed secrets on every push, because they will be committed eventually.
Keeping it maintainable
Pipeline configuration is code and rots like code. Three habits help.
Keep the configuration in the repository it builds, so changes are reviewed alongside the code. Avoid clever scripting inside YAML — if a step needs logic, put it in a script file that can be run locally and tested. And resist the urge to add a stage for every new concern; a pipeline with twenty stages that nobody fully understands becomes a thing people route around.
Metrics worth tracking
Four numbers, widely used and genuinely informative.
- Deployment frequency. Higher is generally better, because it means smaller changes.
- Lead time for change — commit to production. Measures the whole path, not just the pipeline.
- Change failure rate — share of deployments causing an incident.
- Time to restore service after a failed change.
Track them to see direction of travel, not to compare against industry benchmarks. A team going from fortnightly to daily deployment has improved substantially regardless of where that sits against anyone else’s numbers.
Environments without the mess
Environment sprawl is a quiet tax on small teams: a staging that drifts from production, a QA environment nobody maintains, three developer environments configured differently.
Two practices keep it manageable. Create every environment from the same definitions with different parameters, so staging genuinely resembles production — this is one of the main arguments for infrastructure as code. And prefer ephemeral environments created per pull request and destroyed on merge over long-lived shared ones, which accumulate state and configuration nobody can account for.
Ephemeral environments also remove the queue for the shared staging server, which is one of the most common hidden delays in a small team’s delivery cycle.
Starting from nothing
If a team has no pipeline at all, the order that delivers value fastest is narrow.
- Run the tests on every push. Nothing else. Even this changes behaviour, because broken code becomes visible immediately.
- Add linting and formatting, enforced rather than advisory, which ends a whole category of review comment.
- Automate the build and produce a versioned artefact.
- Automate deployment to a staging environment.
- Add smoke tests after deploy.
- Automate production deployment, with an approval step if that is what gets it agreed.
Each step is useful alone, which matters because the project will be interrupted. A pipeline designed to deliver value only when complete usually never completes.
Where to spend the next day of effort
When a pipeline already exists and feels sluggish, three checks usually find the problem faster than a redesign.
Time each stage and look at the longest one. It is almost always dependency installation or an unparallelised test suite, and both have standard fixes.
Count how often builds are re-run without a code change. A high number is the flakiness tax, and it is usually concentrated in a handful of tests that can be identified from the history.
Measure the gap between a merge and the change being live. If a pipeline finishes in eight minutes but deployment waits for a weekly release window, the pipeline is not the constraint and optimising it further will change nothing a developer notices.
Frequently asked questions
How fast should a CI pipeline be?
Under ten minutes for the feedback loop on a pull request. Longer suites can run post-merge or on a schedule.
Should every commit deploy to production?
Continuous deployment works well for teams with strong test coverage and good observability. Continuous delivery — every commit is deployable, deployment is a decision — is a reasonable intermediate step and is where most small teams should start.
Do small teams need staging?
Yes, at least one pre-production environment resembling production. What matters is that it is created and destroyed the same way production is, so it actually tests the deployment path.
How much test coverage is enough?
Coverage percentage is a weak target. Better questions: are the critical paths covered, does the suite catch real regressions, and is it fast enough that nobody skips it?
