Deploy distributed systems faster and safer with contract tests
It’s 2018 and we still rely on integrated environments and large end-to-end test suites to release complex ecosystems, also called “software". In this talk, Matt breaks down the arguments for such nonsense and provides a better, faster, safer alternative.
From https://www.meetup.com/sfjava/events/255379906/
7. Metric Value
No. teams 1
No. components 1
Test environments 1
Time in pipeline (commit to prod) 5 minutes
Risk 2.5%
Deployments per day 10
A STORY > CD HEALTH CHECK
9. Metric Value
No. teams 2
No. components 2
Test environments 4
Time in pipeline (commit to prod) 10 minutes
Risk 5%
Deployments per day 10
A STORY > CD HEALTH CHECK
12. Metric Value
No. teams 3
No. components 6
Test environments 18
Time in pipeline (commit to prod) 30 minutes
Risk 10%
Deployments per day 1
A STORY > CD HEALTH CHECK
15. Metric Value
No. teams 10
No. components 20
Test environments 20 200
Time in pipeline (commit to test) 120+ minutes
Risk 20%
Deployments per month 1
A STORY > CD HEALTH CHECK
24. A STORY > LESSONS > INTEGRATION TESTS
Scam, you say? Justify!
Integrated tests are:
● Slow
● Fragile
● Hard to manage
When they fail, you can’t point to the problem!
25. “But my integration tests run in Docker, why can’t I use
them?”
- People
A STORY > LESSONS > INTEGRATION TESTS
36. A STORY > LESSONS > API DESIGN
How to: dictator driven contracts
1. Sit in ivory tower and postulate
2. Document perfect API (Swagger/OAS etc.)
3. Create said API
4. Publish said document to consumers
5. Repeat steps 1-4
53. Given “User A exists”
When I Receive “a GET request for user A”
With “content-type: application/json”
Respond with “200 OK”
And “User A’s details in the body”
PACT > STEP 1: WRITE A CONSUMER TEST
69. BEST PRACTICES > CHALLENGES
69
1. Sharing and collaborating on pacts between teams
2. Managing contracts across code branches and environments
3. Orchestrating builds to know when it is safe to deploy
71. BEST PRACTICES > PACT BROKER
71
Integrated collaboration tool to and share and manage pacts* between
teams.
● API documentation that is guaranteed to be up-to date
● Visualisations of the relationships between your services
● Dashboards containing contract verification status
● Pact tagging and versioning
● Webhooks for integration and communication
● View pact diffs
● ...and more!
All powered by a RESTful API
72. BEST PRACTICES > PACT BROKER
72
Did I mention README badges and integrations?
76. BEST PRACTICES > PACT BROKER > CAN I DEPLOY?
76
● Verify that a Pacticipant is safe to deploy prior to release
● Enables “matrix” style testing
Consumer Head (1.0.1) Consumer Prod (1.0.0)
Provider Head (2.0.0) ? ?
Provider Prod (1.1.13) ? Already tested
77. BEST PRACTICES > PACT BROKER > CAN I DEPLOY?
77
Can also do with tags...
Consumer Head (‘dev’) Consumer Prod (‘prod’)
Provider Head (‘dev’) ? ?
Provider Prod (‘prod’) ? Already tested
78. BEST PRACTICES > PACT BROKER > “THE MATRIX”
78
$ pact-broker can-i-deploy
--app A --version 1
--app B --version 4
86. Summary
Best Practices
● Pact Broker is key for scaling
● Use webhooks for team communication
○ But… keep build triggers simple!
● Tag pacts to mirror your git branches
● Use can-i-deploy tool for deployment
pre-flight checks
● Update pact tags after deployment to
environment (e.g. prod)
87. Recapping...
● Business impact of integrated tests and environments
● Cause and explanation of those effects
● Alternative approach - isolation + contracts
● Contract-testing as an approach, Pact as a tool (in this order!)
● CDC has its own challenges
○ Not suitable for external/public APIS
○ effective collaboration is the key
88. Thank you
- @matthewfellows
- @pact_up
Given “The presentation is over”
Upon Receiving “A request for an answer”
With “A valid question”
Respond With “A valid answer”
95. Thank you
- @matthewfellows
Given “The presentation is over”
Upon Receiving “A request for an answer”
With “A valid question”
Respond With “A valid answer”