Consumer Driven ContractsQaiser Mazhar

$ whoami● Scrum Master for Baskets & Checkouts

● Joined M&S in March

Previous Life

● Tech Lead & Agile Coach at Rightmove.co.uk

● Search Replacement (Odin)

● Property Data

● Helping other teams and individuals become more “agile”

Odin● Microservices

○ Restful API, JSON over http

○ Java 8, Springboot

○ High quality, clean code

○ Healthy coverage (we did not chase percentage) - Spock, Wiremock, Mockito, AssertJ, Rest-

assured, Gatling, Spring Integration/Web-Integration etc...

○ ELK

○ Monitoring - Xymon, Dashing.io, Spring Health/Metrics, NewRelic

○ Resilience - Hystrix, 3 Site Architecture, Load Balancer

○ ...

● Frontend

○ Mobile first

○ Hand built components

○ Non-isomorphic

Odin● High performing team

○ Autonomy

○ Support what we built

○ Right tool for the job

○ Clear standards and best practices

■ Living documents

○ Strong opinions, loosely held

○ All the DDs (ATDD, BDD, TDD, DDD)

○ CI/CD

○ Promiscuous Pragmatic Pair Programming

○ Sociocratic decision making process

Odin● Challenges

○ Large Team (~12 Devs, 2 QAs, Team Lead, Tech Lead)

○ Lots of learning

■ It's ok to fail as long as there are learnings

○ Lots to do

■ Rearchitecture, CD, Mobile first responsive UI, Agile practices

○ Onboarding new developers

■ Better documentation?

○ Supporting non-CD Teams

○ Breaking changes in APIs

Consumer Driven Contracts● Traditional end to end Tests (Dependency driven)

○ Too late to get feedback

○ Expensive to change so late

○ Difficult to orchestrate

■ Your client might not exist yet

○ Don’t know who is using your software

● Consumer Driven

○ APIs that provide value (and be beautiful )

○ Fail fast

○ Confidence in decommissions

○ Independent deployments

○ Improve communication/collaboration with dependent teams

How does it work?● Centralised contract storage

○ Publish contracts each build

○ Golden source of client dependencies

○ Download and test each build

○ Test both consumer and provider against contract

● A Service can be both provider and consumer

● Frameworks can help:

○ Realestate.com.au pact

○ Thoughtworks pacto

● Stub Provider Service

○ Testing service not downstream

○ Spring @Profile annotation

Creating a new endpoint1. Consumer identifies a need from a provider that is currently not available.

2. Consumer collaborates with service provider to define API to satisfy consumer’s

needs whilst considering the constraints and considerations of the provider.

Result is a contract that the provider must abide by.

3. Provider implements the API to honour the contract, whilst still satisfying all

other existing contracts.

4. Provider runs an automated test to verify the contract has been satisfied as far as

the API is concerned. Functionality is tested via Unit, Integration and other

appropriate tests.

5. Provider publishes changes.

6. Consumer publishes contract and consumes new provider API.

Creating a new endpoint

Consumer ProducerPACT

Consumer ProducerPACT

Consumer ProducerPACT

Updating existing endpoint1. Consumer identifies a change to an existing endpoint for a provider.

2. Consumer collaborates with service provider and any other existing consumers to define API that

will satisfy all consumer’s needs whilst considering the constraints and considerations of the

provider. Result is a contract that the provider must abide by.

3. Provider implements the API to honour the contract, whilst still satisfying all other existing

contracts.

4. Provider runs an automated test to verify the contract has been satisfied as far as the API is

concerned. Functionality is tested via Unit, Integration and other appropriate tests.

5. Provider publishes changes.

6. Consumer publishes new contract, removes old redundant contract and consumes updated

provider API.

7. Remaining consumers publish new contracts, remove redundant contracts and consume updated

provider API.

8. Provider removes deprecated API.

Updating existing endpointConsumer ProducerPACT

Consumer ProducerPACT

Consumer ProducerPACT

Consumer ProducerPACT

Too much of a good thing..● CDCs has most value when working with other teams with independent release

cycles

○ Limited when all consumers ever are in the same small team

● Overhead when rapidly changing API

● Single point of failure for CDC Repository

○ Pick somewhere robust - nexus?

● CDCs can be abused

○ Too loose of a contract

○ Not updated

○ Testing returned values

● CDCs enable conversations, not replace

Other Stuff● Postels Law

● API Versioning

○ Keep only a couple API versions and clean them up

○ Contract with Consumers that only N versions will be supported so they must update regularly

● Rollbacks are more robust

● Discover and Test APIs

○ Swagger/Spring fox

○ README.md

○ Be consistent - don’t make me think