Five Principles for a Reliable CI/CD Pipeline

A good CI/CD pipeline is not the one that runs fast. It is the one you can trust when nobody is watching. Here are five principles that show up in every project I work on.

1. Every build must be reproducible

If running the same build twice gives a different result, you do not have a pipeline - you have a lottery. Pin versions, use lockfiles, and build inside a clean environment.

# Pin the runner and the toolchain, not just the app deps
runs-on: ubuntu-24.04
steps:
  - uses: actions/setup-node@v4
    with:
      node-version: "20.19.5"
      cache: npm
  - run: npm ci   # ci, not install - respects the lockfile exactly

2. Tests run before the deploy, not after

A test that runs after the code is already in production is not a test, it is an alert. Put the quality gate before the release.

3. Rollback should be faster than a forward fix

When something breaks in production, the last thing you want is to fix forward under pressure. A one-click rollback is worth more than any clever patch.

4. Secrets never live in code

Keys, tokens, and passwords go through secret management - not through environment variables forgotten in git. This is not paranoia, it is hygiene.

5. The pipeline itself is code

If the pipeline is configured by clicking through a UI, nobody will know what it does in six months. Define it in code, in review, in git.

None of these five are complicated. They just take discipline. And that is exactly the difference.