Now you have two different sets of tests in two different codebases. The artifacts that tie these tests together are the Pact file, and the verification results. The next step is to automate the exchange of these artifacts.
The Pact Broker is a service that allows your projects to exchange pacts and verification results in an automated way, and to ensure that your application is safe to deploy.
While you can use Pact without a Pact Broker, using one allows you to get the most out of Pact. Pact on its its own allows you to generate and verify contacts. Pact with a Pact Broker allows you to integrate contract tests into your release pipeline. Without the Broker, you will have to work out how to create your own feedback loop that lets the consumer team know the results of the pact verifications, and you will not be able to make use of those results to ensure that each application can be deployed safely.
The following diagram shows what a fully fledged Pact supported release pipeline might look like for a consumer. During this step of the set up guide, we are going just going to cover publishing the pact, and configuring the webhook. The other parts of this pipeline will be covered in later steps.
The following diagram shows what a fully fledged Pact supported release pipeline might look like for a provider. During this step of the set up guide, we are just going to cover the pact verification and results publication. The other parts of this pipeline will be covered in later steps.
Deploy a Pact Broker to a network that has access to both consumer and provider CI systems so it can trigger builds.
Before setting up Pact in your own environment, it can help to have an idea of what a working pipeline might look like. Completing the Pact CI/CD workshop will give you a good understanding of how the Pact client libraries interact with the Pact Broker and where these interactions fit into your release pipeline.
Configure your consumer build to run the Pact tests and publish its pact to the Broker as part of its main build (consult the documentation for your chosen language). Consumer Pact tests typically run after the unit tests, and before deploying to a test environment (see the consumer pipeline diagram above).
Configure your provider build to fetch the pact from the broker and publish the verification results as part of its main build (consult the documentation for your chosen language). This would typically happen after the unit tests, and before deploying to a test environment.
Create a new CI job that performs just the provider pact verification step for a given pact URL (consult the documentation for your chosen language for how to configure this). The job should accept the URL of the changed pact in the HTTP request parameters or body (you'll need to consult the documentation for your CI application to learn how to pass in parameters to a builld).
As you have two different builds running the pact verifications (one when the provider changes, one when the contract changes) it is best to use a provider version number that is deterministic (eg. does not include your CI build number) so that a verification from either job is recorded with the same version number. The recommended approach is to use the git sha (or equivalent for your version control system) wherever possible. This will help you when it comes to using the
can-i-deploy tool in step 7. Please read the section on versioning in the Pact Broker to ensure your version numbers will help you get the most out of your Pact Broker.