Common CI/CD Pitfalls

Most CI/CD failures are not exotic; they are the same handful of mistakes recurring across teams and tooling. Recognizing these patterns early — in code review, in pipeline design, in postmortems — saves far more time than debugging them after they've caused an outage or eroded trust in the pipeline. This topic catalogs the pitfalls that show up again and again, along with the concrete fix for each, so they can be caught by habit rather than rediscovered the hard way.

A flaky test is one that passes and fails intermittently with no code change — often due to timing assumptions, shared test state, or reliance on network calls that occasionally time out. The dangerous pattern is normalizing re-runs: once engineers learn that failure X 'just needs a re-run,' they stop reading failure messages carefully, and a re-run habit that started with one flaky test spreads until real failures get re-run and ignored too. The fix is to quarantine known-flaky tests into a separate, non-blocking suite while they're fixed, rather than leaving them in the blocking path where they train engineers to distrust the pipeline.

Committing an API key, database password, or cloud credential directly into a pipeline YAML file or source code is one of the most common and most damaging pitfalls, because git history retains the secret forever even after it's 'removed' in a later commit. Secrets belong in a dedicated secrets manager or the CI platform's encrypted secret store, referenced by name at runtime, never typed literally into a config file. Equally important: pipeline logs themselves can leak secrets if a command echoes an environment variable or a script prints a full curl command including an Authorization header — most CI platforms automatically mask known secret values in logs, but only if the secret was injected through their secret mechanism rather than pasted as a plain string.

Copy-pasting pipeline YAML across a dozen repositories is a pitfall that seems harmless at first and becomes expensive later: a security fix, a new required check, or a build-tool version bump has to be manually propagated to every copy, and inevitably some repos are missed. Reusable workflows, composite actions, or shared pipeline templates centralize this logic so a fix applies everywhere at once. Similarly, letting a pipeline's actual behavior drift silently from its documentation — someone adds a manual step 'just this once' that never gets written down — erodes the pipeline's trustworthiness as a source of truth for the release process.