Practise vocabulary for integrating contract testing into CI/CD: deployment gates, can-i-deploy, cross-team coordination, and verification workflows.
0 / 5 completed
1 / 5
A contract ___ in CI/CD prevents a service from being deployed if its pact verification is failing.
A deployment gate (quality gate) is a CI step that blocks a deployment unless specific conditions are met. For contract testing, the gate checks that all contracts are verified before allowing deployment.
2 / 5
The Pact `can-i-deploy` command is typically run ___ in the pipeline — before the actual deployment step.
can-i-deploy is a pre-deployment gate that queries the Pact Broker to confirm all contract verifications are passing for the version being deployed. If any verification fails, the deployment is blocked.
3 / 5
When a provider CI pipeline detects a failing pact verification, the correct response is to ___.
A failing pact verification should block the provider's deployment — the provider has made a breaking change. The provider team must either fix the change or negotiate an update with the consumer team.
4 / 5
Bi-directional contract testing (available in Pactflow) works by comparing the ___ from both sides rather than running live verifications.
Bi-directional contract testing compares the provider's OpenAPI spec against the consumer's Pact contract statically, without running a live provider. This is faster and works well when providers already have an OpenAPI spec.
5 / 5
'Our pipeline triggered your verification build' in cross-team contract testing means the consumer's pact publication caused the ___ to run a new verification.
The Pact Broker can send webhooks to the provider's CI when a new pact is published, triggering a provider verification build automatically. This creates a feedback loop where consumers instantly know if their new contract is satisfied.