Practise vocabulary for the Pact workflow: publishing pacts, provider verification, the Pact Broker, can-i-deploy, and CI integration.
0 / 5 completed
1 / 5
After consumer tests run and generate a pact file, the next step is to ___ the pact to the Pact Broker.
Publishing the pact uploads the contract JSON to the Pact Broker, making it available for the provider to retrieve and verify. The broker stores pacts with version tags and branch information.
2 / 5
Provider verification is the process where the ___ runs the pact interactions against a real instance of the service to confirm it satisfies the contract.
Provider verification runs each interaction from the pact against a real (or realistic) provider instance. The provider sets up the declared provider state, makes the request, and checks the response matches the contract.
3 / 5
The `can-i-deploy` Pact CLI command answers the question: 'Is it safe to deploy ___ to production given the current contract verification status?'
can-i-deploy checks the Pact Broker to see if a specific version of a service has been verified by all its consumers and providers. It acts as a deployment gate, preventing releases that would break dependent services.
4 / 5
A ___ pact in Pact Broker is one that has been published by a consumer but not yet verified by the provider — it's in a provisional state.
A pending pact has been published but not yet verified by the provider. By default, pending pacts don't fail the provider's verification build — they're 'in progress' contracts that won't block the provider's pipeline.
5 / 5
When a pact verification ___, it means the provider's current implementation no longer satisfies the consumer's expected interactions.
A pact verification failure means the provider has made a change that breaks the consumer's expected contract. This should block the provider's deployment and trigger communication with the consumer team.