CI/CD for small teams: a practical starting point

CI/CD (continuous integration and continuous delivery) sounds like something for large engineering teams. It isn't. For a small team it matters more, because there's no one whose full-time job is to check releases by hand, and every hour lost to a broken deploy is an hour of a small team's week.

The goal is simple: every change gets tested the same way, goes live the same way, and can be undone quickly if something's wrong. Here's what that looks like, in the order we'd build it.

1. Everything starts from the repository

Before any automation, make sure the repository holds everything needed to build and run the software: the code, the configuration (without secrets), and a written way to start it locally.

• One main branch that always reflects what's live or about to be
• Short-lived branches for changes, merged through pull requests
• Secrets in the hosting platform or a secrets manager, never in the code

If a new developer can't get the project running from the README in an hour, fix that first. Automation built on a project nobody can run reliably just fails faster.

2. Run checks on every pull request

Continuous integration means every proposed change is checked automatically before it's merged. Start small:

1. Install dependencies and build the project
2. Run the linter and type checks
3. Run the tests you have, even if there aren't many

The rule is that nothing merges unless the checks pass. Most code hosts (GitHub, GitLab, Bitbucket) have this built in and free for small teams. Ten minutes of setup here prevents a whole class of "it worked on my machine" problems.

Don't wait for perfect test coverage. Add a test whenever a bug is fixed, and coverage grows where it matters most.

3. Deploy automatically from the main branch

Continuous delivery means a merge to the main branch produces a release without anyone running commands by hand. The pipeline:

1. Builds the application once, into an image or bundle
2. Tags it with the commit it came from
3. Deploys that exact build to production

Building once and deploying the same artefact matters: what you tested is exactly what goes live. If you have a staging environment, deploy the same build there first.

4. Add preview environments

A preview environment is a temporary copy of the application for a single pull request, with its own link. It lets a product owner, designer or client try a change before it's merged, instead of reviewing screenshots.

Many hosting platforms can create previews automatically. Even a simple version, one shared preview that always shows the latest open pull request, makes reviews faster and catches problems that tests miss.

5. Make rollback a single step

Things will go wrong. What matters is how quickly you can undo them. Because each release is a tagged build, rolling back should mean redeploying the previous one: one command or one click, not a scramble.

Two habits make this work:

• Keep database changes backwards-compatible. Add new columns before code uses them, and remove old ones only after code stops using them. Then the previous release still works against the current database.
• Practise it. Roll back on purpose once, when nothing is on fire, so you know it works.

6. Know when something breaks

A pipeline that deploys reliably is only half the job. You also need to know when production is unhealthy, before your customers tell you.

• Uptime checks on the main pages and API, from outside your infrastructure
• Error tracking that groups errors and shows which release introduced them
• Alerts that reach a person: a message to the team chat or a phone, not an inbox nobody reads

Start with these three. Dashboards and detailed metrics can come later.

What it costs

For a small team, most of this runs on tools you may already pay for: your code host's built-in CI, your hosting platform's deploys and previews, and a monitoring service with a free or low-cost tier. The real cost is the set-up time, usually days rather than weeks for a typical web application, and it's repaid the first time a bad release is rolled back in a minute instead of an evening.

Where to start

If you have nothing today, do it in this order: checks on pull requests, automatic deploys, monitoring and alerts, then previews and practised rollbacks. Each step is useful on its own, so you get value from the first day.

If you'd like help setting this up, or taking over infrastructure another team built, talk to us or read more about our DevOps work.