In the previous post, we walked through what happens when a contract genuinely breaks, and how tagging and versioning give both teams a precise way to reason about it. This last post in the series pulls every piece we have built, consumer tests, the broker, provider verification, and can-i-deploy, into one coherent pipeline view, so it is clear how this actually runs day to day rather than as a sequence of separate manual steps. ...
In the previous post, can-i-deploy gave checkout an automated gate that blocks a deploy when payment has not verified the current contract. That check is only as good as the version history behind it. This post looks at how Pact tracks that history, and what actually happens in the broker when a contract changes in a way that breaks an existing consumer. Every Contract Publish Is a New Version Each time checkout runs pact:publish, it does not overwrite the previous contract. It adds a new version, tied to whatever identifier you passed in, normally a git commit hash. The broker keeps every version, along with which provider versions have verified each one. This is what makes can-i-deploy meaningful. It is not asking “has this contract ever passed,” it is asking “has this specific version passed.” ...
In the previous post, both checkout and payment started publishing contracts and verification results to a shared Pact Broker. The broker knows exactly which version of payment has verified exactly which version of checkout’s contract. What it does not do on its own is stop anyone from deploying a version that has not been verified. That is what can-i-deploy is for. The Question It Answers Before checkout deploys a new version to production, there is one question worth asking automatically rather than trusting someone to remember it. Has every provider checkout depends on already verified this exact version of the contract. If the answer is no, the deploy should not happen, full stop. ...
In the previous post, payment verified checkout’s contract by reading it from a local folder path. That works for a demo, but it does not scale. The provider team should not need a copy of the consumer’s build output sitting on disk to run their tests. This is what the Pact Broker exists to fix. What the Broker Actually Does A Pact Broker is a small standalone service that stores contracts, tracks which versions of which services have verified which contracts, and exposes that history through a web UI and an API. Instead of checkout emailing a JSON file to payment, checkout publishes its contract to the broker after every build, and payment pulls the latest version from the broker when it runs verification. ...
In the previous post, checkout’s test suite generated a real contract file describing two interactions with the payment service, an authorized payment and a declined one. That file sitting in target/pacts proves nothing about payment’s actual behavior yet. This post covers the other half of Pact, taking that same file and replaying it against payment’s real implementation. Adding the Provider Dependency On the payment service side, add Pact’s provider JVM module. ...
In the previous post, we added the Pact JVM dependency and sketched out a contract definition for authorizing a payment. That definition on its own does not generate anything yet. We still need a test method that actually exercises it, by calling real client code against Pact’s mock server. That is what turns a description of an interaction into a generated contract file on disk. Connecting the Test to the Mock Pact’s JUnit 5 extension injects a MockServer into your test method, giving you the actual host and port the mock is running on. Your job is to point your real HTTP client at that address instead of the real payment service. ...
In the previous post, we covered why contract testing exists and where Pact fits between unit tests and full integration tests. Before we can write an actual contract, we need Pact wired into the project. This post is the setup step, getting a Spring Boot service ready to generate its first contract. Adding the Dependency Pact JVM ships a JUnit 5 module that plugs straight into the test framework you are probably already using. For a Maven project, add this to the checkout service’s pom.xml. ...
Every team running more than a handful of microservices eventually hits the same wall. Integration tests that spin up three or four real services are slow and flaky. End-to-end tests that go through the whole system catch real problems, but only after everything is already deployed, and a single unrelated service being down fails the whole suite. Somewhere in between those two extremes sits a much cheaper question. Does my service still honor what the other services expect from it. ...