Can-I-Deploy Gate

A provider has contract tests. They pass on every build. Consumers still break in production, and each incident ends with someone asking what the contract tests are for.

The gap is not coverage. It is that nothing consults the contracts at the moment a deployment is decided. A passing test says a pair was compatible at some point. The deploy needs a different fact: whether this version is compatible with what is running there now.

Why it matters

Independent deployability is the property microservices are bought for, and it is exactly the property that a shared integration environment or a manual coordination call takes away. The gate is what makes independence safe: a provider team ships when the matrix says the environment's consumers are covered, without asking anyone.

It also converts a class of production incident into a pipeline failure that costs 2 minutes, which is the only trade in testing that is unambiguously good.

Implementation patterns

• Record deployments, not just verifications. The broker must know which consumer versions are live per environment, which means the deploy pipeline tells it — on success and on rollback.
• Query before release, with a fast answer. Under 2 seconds is achievable and it matters, because a gate that adds 10 minutes to a 15 minute pipeline is disabled within a month.
• Pending contracts for new expectations. A consumer publishing an expectation the provider has not implemented must produce a report, not a red provider build, or consumers learn to stop publishing and the whole scheme decays.
• Scope verification to deployed versions with a compatibility window, so old consumer versions age out instead of constraining the provider forever.
• Branch and environment tags, so a check against staging cannot be mistaken for a check against production.

Industry example

The pattern is codified in the Pact ecosystem's broker and its can-i-deploy command, which is the reference implementation most organisations either adopt or reimplement. Teams running dozens of consumer services per provider converge on the same three moving parts regardless of tooling — recorded deployments, verified pairs and a query at the gate — because the alternative at that fan-out is a nightly integration environment whose failures arrive after merge with every team's changes mixed together.

Failure scenarios

• Verification against every contract ever recorded, which grows without bound and eventually blocks a release over an expectation from a version nobody runs.
• Stale deployment records, so the gate answers about an environment that no longer exists. This is the silent one: the query returns green and means nothing.
• Consumers that stop publishing because their expectations broke the provider's build.
• A gate on staging only, which certifies compatibility with a set of versions that production does not have.
• Semantic breaks a schema check misses: a new enum value a consumer switches on, a field becoming optional, an ordering guarantee quietly dropped.

Trade-offs

The gate costs a broker to run, discipline in the pipeline to report deployments, and a genuine constraint on the provider: you cannot ship a breaking change until consumers have moved, which is the point and is sometimes inconvenient. The alternative costs a shared environment, a coordination meeting, or an incident. For a provider with many independent consumers this is one of the better trades available.

When not to use it

Below roughly five consumers inside one repository, prefer a build that compiles everything together — it is stricter, faster and free. If consumers cannot deploy independently anyway, the broker adds ceremony without adding the capability it exists to protect, and it will hide the fact that you have a distributed monolith rather than fix it.

Interview question

Q: You have 40 consumers of one API, a 15-minute pipeline and existing contract tests that do not prevent breakage. Design the change, and tell me what happens on the day a consumer publishes an expectation you have not implemented.

What a strong answer covers: the deploy-time query and the three facts it needs · recorded deployments per environment including rollbacks · pending contracts so the new expectation reports rather than blocks · scoping and compatibility windows so verification does not grow forever · acknowledging what a schema compatibility check does and does not catch · and the honest statement that the gate constrains the provider deliberately.

Quick check

Quiz: What three facts must a deploy-time compatibility query have? The version being deployed, the versions live in that environment, and a successful verification for each pair.

Flashcard: Why must a new consumer expectation be pending rather than blocking? — Otherwise a consumer can break the provider's build by publishing, so consumers stop publishing and the scheme decays.