How to Set Up CI/CD for a Small Team

JetBrains describes trunk-based development as committing changes directly to the main branch, the trunk, instead of developing features or bug fixes in separate branches and merging them at some later stage. The goal is to keep the main branch healthy and releasable at all times.

For a small team the practical version is this.

1. Branch per change, not per feature. Open a branch, make one focused change, open a pull request the same day or the next.
2. Merge within a day or two. Travis CI's explainer notes that the longer developers take, the harder the merge, and that developers would have forgotten what they had done by the time they resolve conflicts.
3. Hide unfinished work behind a flag. If a feature takes two weeks, merge it in small pieces that are switched off in production.
4. Fix a broken main before anything else. A red main blocks everyone, so the person who broke it fixes or reverts it immediately.

Avoid long-lived develop or release branches unless you ship software that customers install and you must patch old versions. For a web application, one main branch plus short-lived branches is enough.

Start with a pipeline that runs on every pull request and every push to main. It should answer one question quickly: is this change safe to merge?

GitHub Actions is the natural starting point for teams that already host code on GitHub. The documentation explains that workflows can run on GitHub-hosted machines or your own, and that GitHub runs your CI tests and provides the results of each test in the pull request. Workflows live as YAML files in .github/workflows/, and the workflow syntax reference documents every key.

A first workflow for a Node.js project looks like this.

name: ci
on:
  pull_request:
  push:
    branches: [main]

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<pinned-sha>
      - uses: actions/setup-node@<pinned-sha>
        with:
          node-version-file: .nvmrc
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

The concurrency block cancels an older run on the same branch when a newer commit arrives, which saves minutes and avoids confusing results. Pin each action to a specific release or commit SHA, shown here as a placeholder, so an upstream change cannot alter your pipeline without a commit in your repository.

Then add stages in this order as the project grows.

Keep one build script for laptops and CI. As trunkbaseddevelopment.com puts it, the build script which developers run prior to checking in, is the same one which is followed by the CI service. Put the commands in package.json, a Makefile or a task runner, and have the workflow call them. CI then verifies the same thing you checked on your laptop.

A common mistake is building the application separately for staging and for production. Each build can pull slightly different dependencies or pick up different environment settings, so the thing you tested is not the thing you shipped.

Harness describes the alternative as building once and promoting the same artifact through every stage of testing and deployment, a practice it calls artifact immutability. In practice:

• Build a container image, a zip or a static bundle once, tagged with the commit SHA.
• Store it in a registry or artifact store.
• Deploy that exact tag to staging, test it, then deploy the same tag to production.
• Inject environment differences such as database URLs and API keys at runtime, never at build time.

Tagging by commit SHA also gives you a clean audit trail. Anyone can answer "what is running in production" by reading one tag and finding the commit.

Every team eventually ships a bad release. What matters is how long it takes to recover. Octopus Deploy's guide to rollback strategies starts with an uncomfortable scenario: the rollback scripts were never tested, and the last rollback happened years ago. Its advice is to measure strategies by recovery time, from problem found to service restored.

Three principles from that guide fit small teams well.

1. Roll back code by redeploying the previous artifact. If you build once and tag by commit, rolling back is deploying the previous tag. Octopus describes a simple strategy that redeploys the previous version and skips database steps, and notes that a breaking schema change prevents rollbacks, leaving only a roll forward.
2. Do not roll back the database. The guide warns that both rollback scripts and backup restores will likely lose data written since the release.
3. Make database changes compatible with the previous release. Deploy schema changes before the code that needs them, using the expand and contract pattern: add the new column or table first, ship code that uses it, and remove the old structure only in a later release. Then the previous code version still works if you need to redeploy it.

Write the rollback steps down and run them once on staging. A rollback you have never practiced is a guess.

A CI system can read your source code and deploy to production, which makes it one of the most valuable targets in your stack. Harness recommends starting with the basics: keeping secrets out of source control, limiting who can change pipelines and environments, and requiring SSO and multi-factor authentication.

For a small team that translates into a short list.

• Store secrets in the CI provider's secret store, never in the repository, and never print them in logs.
• Give each environment its own credentials. A staging key should not work against production.
• Grant the pipeline the minimum permissions it needs. Test jobs need read access to the repository, and only the deploy job needs credentials that can change production.
• Require approval for production deploys using protected environments or a manual gate.
• Scan dependencies on every pull request so a known vulnerable package is flagged before merge.
• Do not run untrusted pull request code with access to secrets, which matters most for public repositories.

A pipeline that takes forty minutes or fails at random gets bypassed. GitLab's guide points to Martin Fowler's ten-minute build as a target most modern projects can reach, and notes that every minute saved is saved for every developer on every commit.

Ways to keep it fast:

• Cache dependencies between runs.
• Run independent jobs in parallel, such as lint, unit tests and type checks.
• Split slow test suites across several runners. Harness suggests parallelizing so total test time depends on your infrastructure, not just the size of the codebase.
• Push expensive end-to-end tests later in the pipeline, after the fast checks pass.

Ways to keep it trusted:

• Treat flaky tests as bugs. Quarantine a flaky test immediately and fix it, because a team that learns to rerun failures stops reading them.
• Measure the pipeline. Track how long runs take, where they fail and how often deploys need rollbacks, as Harness recommends, and fix the worst stage first.
• Review failures without blame. GitLab advises looking for patterns in failed builds and making failures blameless, so people report problems rather than hide them.

Teams using AI coding agents benefit twice from a strong pipeline, because the agent gets the same fast, objective feedback a person does. Quanta Intelligence playbooks can encode the pipeline conventions above so agents write code that passes them on the first run.