What CI/CD is for
The job of the pipeline — fast feedback, reproducible artifacts, and controlled path to production.
CI/CD is not “run Jenkins.” It is a product capability: every change is integrated, proven, and shippable through the same path.
What good looks like
- Fast feedback on every commit or PR — broken main is rare and short-lived
- One artifact promoted across environments (same bits, different config)
- Automated gates that encode what “safe to ship” means
- A boring rollback or forward-fix story when production disagrees
What it is not
- A replacement for design review, observability, or on-call ownership
- A place to hide manual snowflake deploys “just this once”
- Infinite stages that take hours and teach people to bypass them
If engineers routinely skip the pipeline, the pipeline is the bug.
CI vs CD
Continuous integration merges and verifies often so integration pain stays small.
Continuous delivery keeps main always in a releasable state; humans (or policy) choose when to promote.
Continuous deployment promotes automatically when gates pass. That is a deliberate product and risk choice — not a moral upgrade.
Smell test
Ask: Can a new engineer ship a one-line fix with the same path as a major feature? If no, you have folklore, not CI/CD.