API Changes Break Consumers Without Warning
Breaking API changes reach all consumers simultaneously. Teams are afraid to evolve APIs because they do not know who depends on them.
Deployment and Release Problems
Symptoms related to deployment frequency, release risk, coordination overhead, and environment parity.
less than a minute
These symptoms indicate problems with your deployment and release process. When deploying is painful, teams deploy less often, which increases batch size and risk. Each page describes what you are seeing and links to the anti-patterns most likely causing it.
How to use this section
Start with the symptom that matches what your team experiences. Each symptom page explains what you are seeing, identifies the most likely root causes (anti-patterns), and provides diagnostic questions to narrow down which cause applies to your situation. Follow the anti-pattern link to find concrete fix steps.
Related anti-pattern categories: Pipeline Anti-Patterns, Architecture Anti-Patterns
Related guides: Pipeline Architecture, Rollback, Small Batches
The Build Runs Again for Every Environment
Build outputs are discarded and rebuilt for each environment. Production is not running the artifact that was tested.
Every Change Requires a Ticket and Approval Chain
Change management overhead is identical for a one-line fix and a major rewrite. The process creates a queue that delays all changes equally.
Multiple Services Must Be Deployed Together
Changes cannot go to production until multiple services are deployed in a specific order during a coordinated release window.
Work Requires Sign-Off from Teams Not Involved in Delivery
Changes cannot ship without approval from architecture review boards, legal, compliance, or other teams that are not part of the delivery process and have their own schedules.
Database Migrations Block or Break Deployments
Schema changes require downtime, lock tables, or leave the database in an unknown state when they fail mid-run.
Every Deployment Is Immediately Visible to All Users
There is no way to deploy code without activating it for users. All deployments are full releases with no controlled rollout.
The Team Is Afraid to Deploy
Production deployments cause anxiety because they frequently fail. The team delays deployments, which increases batch size, which increases risk.
Hardening Sprints Are Needed Before Every Release
The team dedicates one or more sprints after “feature complete” to stabilize code before it can be released.
Releases Are Infrequent and Painful
Deploying happens monthly, quarterly, or less. Each release is a large, risky event that requires war rooms and weekend work.
Merge Freezes Before Deployments
Developers announce merge freezes because the integration process is fragile. Deploying requires coordination in chat.
No Evidence of What Was Deployed or When
The team cannot prove what version is running in production, who deployed it, or what tests it passed.
Deployments Are One-Way Doors
If a deployment breaks production, the only option is a forward fix under pressure. Rolling back has never been practiced or tested.
Teams Cannot Change Their Own Pipeline Without Another Team
Adding a build step, updating a deployment config, or changing an environment variable requires filing a ticket with a platform or DevOps team and waiting.
New Releases Introduce Regressions in Previously Working Functionality
Something that worked before the release is broken after it. The team spends time after every release chasing down what changed and why.
Releases Depend on One Person
A single person coordinates and executes all production releases. Deployments stop when that person is unavailable.
Security Review Is a Gate, Not a Guardrail
Changes queue for weeks waiting for central security review. Security slows delivery rather than enabling it.
Services Reach Production with No Health Checks or Alerting
No criteria exist for what a service needs before going live. New services deploy to production with no observability in place.
Staging Passes but Production Fails
Deployments pass every pre-production check but break when they reach production.
Deploying Stateful Services Causes Outages
Services holding in-memory state drop connections, lose sessions, or cause cache invalidation spikes on every redeployment.
Features Must Wait for a Separate QA Team Before Shipping
Work is complete from the development team’s perspective but cannot ship until a separate QA team tests and approves it. QA has its own queue and schedule.