Missing Deployment Pipeline
Builds and deployments are manual processes. Someone runs a script on their laptop. There is no automated path from commit to production.
less than a minute
These anti-patterns affect the automated path from commit to production. They create manual steps, slow feedback, and fragile deployments that prevent the reliable, repeatable delivery that continuous delivery requires.
Builds and deployments are manual processes. Someone runs a script on their laptop. There is no automated path from commit to production.
The build is automated but deployment is not. Someone must SSH into servers, run scripts, and shepherd each release to production by hand.
Each environment is hand-configured and unique. Nobody knows exactly what is running where. Configuration drift is constant.
Servers are provisioned manually through UIs, making environment creation slow, error-prone, and unrepeatable.
Connection strings, API URLs, and feature flags are baked into the build, requiring a rebuild per environment and meaning the tested artifact is never what gets deployed.
Dev, staging, and production are configured differently, making “passed in staging” provide little confidence about production behavior.
Multiple teams share a single staging environment, creating contention, broken shared state, and unpredictable test results.
Pipeline definitions are maintained through a UI rather than source control, with no review process, history, or reproducibility.
Credentials live in config files, environment variables set manually, or shared in chat - with no vault, rotation, or audit trail.
Every build starts from scratch, downloading dependencies and recompiling unchanged code on every run.
After deploying, there is no automated verification that the new version is working. The team waits and watches rather than verifying.
Code that behaves differently based on environment name (if env == ‘production’) is scattered throughout the codebase.