What to automate first in a CI/CD pipeline

Start with the path from commit to production

Teams that try to automate everything at once usually end up with a pipeline nobody trusts. A better starting point is to write down what actually happens between a merged commit and a running release, including the steps that live in someone's head.

Mark each step as manual or automated, then ask two questions: how often is it repeated, and what is the cost when it goes wrong? The steps that are both frequent and risky are the ones to automate first.

1. Build once, in a reproducible way

The first thing worth automating is the build. Pin your toolchain and dependency versions, build in a clean environment, and produce a single versioned artifact, such as a container image tagged with the commit SHA.

The rule that pays off most is to build once and promote the same artifact through every environment. If staging and production run different builds, staging stops being evidence about production.

2. Run the fast checks on every change

Next, run linting, type checks, and unit tests automatically on every pull request. Keep this stage fast enough that people wait for it instead of working around it. Slow suites are best split: quick checks gate the merge, and longer integration or end-to-end suites run in parallel or after merge.

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

3. Turn deployment into a command, not a procedure

A deployment that depends on a wiki page and a careful engineer is a deployment that will eventually go wrong. Script it, run it from the pipeline, and use the same mechanism for every environment so the process is exercised constantly rather than only on release day.

4. Automate the way back

Rollback is part of the release, not an emergency improvisation. Keep the previous artifact available, make redeploying it a one-step action, and test that path on purpose.

Database changes are the usual complication. Prefer backward-compatible migrations, where you add first, deploy the code, and remove old structures in a later release, so that the previous version of the application still works against the new schema.

5. Add gates where the risk actually is

Only after the basics are stable is it worth adding the heavier controls:

• Dependency and container image vulnerability scanning.
• Secret scanning on commits and pull requests.
• Required reviews or approvals for production deployments.
• Smoke tests and automated health checks after each deployment.
• Progressive delivery, such as canary or blue-green releases, for services where a bad release is costly.

What it is fine to leave manual for now

Not every step deserves automation. Rare, low-risk tasks and decisions that need human judgment, such as approving a production release for a regulated system, can stay manual as long as they are documented. The goal of a CI/CD pipeline is not zero humans. It is making the repeated, error-prone work boring so people can spend attention where it matters.