Pact is a tool for consumer-driven contract testing. It’s a way of testing the integration between microservices without performing end-to-end testing.
“Consumer-driven” means that the consumer of a service sets expectations about behaviour it needs from the provider.
For example, the publishing API is set up to run pact tests. This means that any consumer of the publishing API can create contracts using the pact gem, and the publishing api deployment pipeline will check that consumers’ contracts are still met by new builds.
The Pact Broker is a repository for all the contracts. The consumers publish to it, and the producers query from it when they run the tests.
Information you need to know
- It runs on the Government PaaS at https://pact-broker.cloudapps.digital/
- It is deployed from https://github.com/alphagov/govuk-pact-broker
Accessing and logging on
The application is open to the internet with no authentication for read requests. Write requests are restricted with HTTP basic auth. These credentials are exposed as environment variables to jobs on CI to enable them to publish pacts to the broker.
About the app itself
Pact Broker stores its data in a PostgreSQL database. The location and creds for
this are passed in the
DATABASE_URL environment variable.
The app logs to
Out of the box, the Pact Broker allows uploading of pact files with semver style versions (eg 2.0.1). For our usage, we wanted to be able to upload pact files from various branches in addition the released versions so that our branch builds of consumers can verify their pactfiles with the producers.
Pact Broker allows us to implement our own versioning scheme by providing a custom version parser. We’ve used this to extend the versioning scheme to allow branch builds to be uploaded as well. In addition to numeric versions, our scheme allows for “master”, and “branch-foo” versions to be uploaded. These will always be ordered after any numeric versions, so the ‘latest’ pactfile from the pact brokers POV will always be the highest numeric version.