I see many teams claim they have “CI/CD” because they have a Jenkins or GitHub Actions pipeline that runs tests. But if your process involves a “Freeze Week” or a “Manual QA Sign-off” that takes 3 days, you don’t have CI/CD. You have an automated build process.

The Goal: Confidence

The goal of CI/CD isn’t to run scripts. It’s to give the team enough confidence that a commit can go to production without human intervention.

The “Scary” Deploy

If deploying to production is a “scary” event that requires everyone to be on a Zoom call, your feedback loop is broken. Deploys should be boring. So boring that they happen 10 times a day and nobody notices.

How to get there?

  1. Automated Testing (The real kind): Not just unit tests. You need integration tests and “smoke tests” that run against a real-ish environment.
  2. Feature Flags: This is the secret sauce. Separate Deployment from Release. Deploy the code behind a flag, then turn it on for 1% of users. If the errors don’t spike, go to 10%.
  3. Small PRs: If a PR has +2,000 lines, nobody is actually reviewing it. They’re just LGTM-ing it because they’re tired. Small PRs = fast reviews = fast CI.

Continuous is a Mindset

It’s not about the tools you use. It’s about the trust you have in your automated systems. If you can’t trust your tests to catch a breaking change, don’t fix the pipeline—fix the tests.

Stop the “deploy trains” and start the continuous flow.