The consumer CI generates pact files during the execution of its isolated tests. The provider CI generates verification results during the execution of its isolated tests. These artifacts need to be shared between the projects.
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 here.
This is where the Pact Broker comes in. It enables you to share your pacts and verification results between projects, and make them useful for people too. It is the recommended way forward for serious Pact development.
The Pact Broker:
- allows you to release customer value quickly and confidently by deploying your services independently and avoiding the bottleneck of integration tests
- solves the problem of how to share contracts and verification results between consumer and provider projects
- tells you which versions of your applications can be deployed safely together
- automatically versions your contracts
- allows you to ensure backwards compatibility between multiple consumer and provider versions (eg. in a mobile or multi-tenant environment)
- provides API documentation of your applications that is guaranteed to be up-to date
- shows you real examples of how your services interact
- allows you to visualise the relationships between your services
- A RESTful API for publishing and retrieving pacts.
- An embedded API browser for navigating the API.
- Autogenerated documentation for each pact.
- Dynamically generated network diagrams so you can visualise your microservice network.
- Displays provider verificaton results so you know if you can deploy safely.
- Provides a "matrix" of compatible consumer and provider versions, so you know which versions can be safely deployed together.
- Provides badges to display pact verification statuses in your READMEs.
- Enables an application version to be tagged (ie. "prod", "feat/customer-preferences") to allow repository-like workflows.
- Provides webhooks to trigger actions when pacts change eg. run provider build, notify a Slack channel.
- View diffs between Pact versions so you can tell what expectations have changed.
- Docker Pact Broker
- A CLI for encorporating the Pact workflow into your continuous integration process.
Most importantly, the
Pact Broker allows you to easily decouple the release cycle of your
Provider, which is one of the goals of writing microservices in the first place.
Read the pages in the Pact Broker quick start guide to get up and running with the basics. You'll find a helpful checklist of changes you need to make to integrate Pact into your CI pipeline, as well as links to more detailed information on Broker usage.
You can find all the documentation for the
Pact Broker in the Pact Broker wiki.
Command line interface
For Mac, Windows and Linux. Allows you to integrate the contracts workflow into your CI. Download here.
Ruby via the
Pact JVM - Gradle
Pact JVM - JUnit
Pact JVM - SBT
Pact JVM - Maven
Example publishing with PowerShell:
See the full API.
Manual via HTTP
- See the API definition with
For more information head over to the Pact Broker website.
Consumer CI build commits pact to
Pretty self explanatory.
2. Publish pacts as CI build artefacts
Work out the URL to the pact created by the most recent successful build, and configure the pact:verify task to point to this URL.
3. Use Github/Bitbucket URL
This only works for repositories that don't require authentication to read. Make sure that you always regenerate the pacts before committing if you make any changes to the pact specs, and that the specs are always passing before you commit, because you don't want to verify the pact from a broken build.
4. Publish pacts to Amazon S3
Pact::Retreaty is a tool which provides a ultra light mechanism for pushing and pulling pact contracts to/from S3.