4. Automate the contract and verification results exchange

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.

Quick Start

The Pact Broker is an open source tool that requires you to deploy, administer and host it yourself. If you would prefer a plug-and-play option, we've created Pactflow, a fully managed Pact Broker with additional features to simplify teams getting started and scaling with Pact.

Get started for free on our Developer Plan.

Consumer pipeline

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.

Consumer release pipeline

Provider pipeline

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.

Provider release pipeline

A. Set up a Pact Broker

  1. Read the Pact Broker home page, (taking note of the various deployment options available to you) and the quick start guide, or sign up to a hosted Developer plan at Pactflow.

  2. Deploy a Pact Broker to a network that has access to both consumer and provider CI systems so it can trigger builds.

B. Do the CI/CD workshop

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.

Note that if you are using your own instance of the open source Pact Broker, it does not support secrets, and it does not have a user interface for managing webhooks. You'll need to use the API to create the webhook, and your Travis CI token will have to be stored in plain text in the webhook.

C. Configure pact publication

  1. 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).

D. Configure pact to be verified when provider changes

  1. 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.

E. Configure pact to be verified when contract changes

  1. 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).

  2. Configure a webhook to kick off the provider verification build when a pact changes, and use webhook templates to pass the URL of the changed pact to the build.

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.

Useful links: