CI/CD for startups: Ship every Friday without breaking production

Small teams rarely slow down for want of tooling; they slow down because every release is a bespoke event that one person fully understands and nobody wants to begin late in the week.

The workflow that lets a team of five ship daily is not a smaller version of an enterprise release process. It is a different shape: fewer branches, shorter changes, and a pipeline nobody reads the logs of unless it goes red.

Most of the practices below cost an afternoon each to set up. They get skipped because the pain of a manual release is spread thinly, so it never becomes a job that belongs to anyone.

Trunk-based development in practice

Long-lived feature branches are the main source of release risk in a small team. A branch that lives three weeks accumulates conflicts, hides its work from the test suite and turns integration into a separate project.

We work on main with short branches lasting hours or days, merging behind a flag when the work is unfinished. What makes that safe is small, complete increments. Five rules keep the trunk shippable:

1. Main is always deployable, and a red build outranks new work.
2. Branches merge within a day or two, or are split until they can.
3. Unfinished work goes in behind a flag rather than waiting out on a branch.
4. Reviews cover the change, not the accumulated state of a long branch.
5. Nobody merges a change they cannot describe how to reverse.

The practical test is whether a new engineer could merge something on their first day. If that is unthinkable, the bottleneck is process rather than seniority.

Test suites fast enough to trust

A slow suite gets skipped, and a flaky suite gets ignored, which is worse. Speed and determinism matter more than a coverage figure, because together they decide whether anyone waits for the result.

A fast layer runs on every push — unit tests, type checks, linting — and a slower layer covers the few journeys that carry revenue. Everything else is a candidate for deletion rather than repair.

Flaky tests are quarantined the same day and fixed or removed within the week. A suite kept honest stays a signal; one carrying a standing list of known failures has stopped being one.

Preview environments and migrations

Every pull request gets an ephemeral environment with its own database, seeded from a sanitised snapshot. That is what lets a designer or a founder look at the change rather than read about it.

Schema migrations cannot be rolled back cleanly, so they ship separately from the code that depends on them. Add the column, write to both shapes, backfill, move reads across, then drop the old one.

Expand and contract takes four deploys where an in-place change takes one, and it is the difference between a bad migration being an inconvenience and an outage with no way back.

Flags, rollback and release hygiene

Deployment and release become separate events once flags are in place, and that separation is what makes a Friday unremarkable.

• Flags with owners: each has an owner and a removal date, or dead branches accumulate.
• Rollback before fix-forward: the first response to a bad deploy is the previous artefact, not a hurried fix.
• Immutable builds: the artefact tested in CI is the one promoted, with configuration injected per environment.
• Progressive exposure: a new path reaches internal users, then a slice of traffic, then everyone.
• One release dashboard: error rate, latency and the main conversion event, watched after each deploy.

Making the checklist smaller

A release checklist is a list of the things the pipeline does not do yet. Each manual step reads as a defect: the smoke test run by hand, the cache someone remembers to clear, the migration applied from a console.

Automating one item per release cycle takes a small team to a one-click deploy within a quarter, with no platform hire. Shipping on a Friday then says something about the pipeline rather than about courage.

• engineering
• operations