Contract Driven Development: The Death of Integration Hell
In a complex, interdependent eco-system, where each service is evolving rapidly, we typically end up with an Integration Hell .i.e. the myriad problems that occur when API integrations break down * Provider and consumer integrations break when their understanding of the API endpoints are out of sync * Working integrations break when the API developer makes a change without informing the consumer * Development and testing slow down when the consumer depends on the provider API running in a staging environment: ** The network may be down ** The environment hosting the API may be down ** The staging API may crash, or may not even be started ** Development can be delayed if the staging API is not kept up-to-date ** API changes can come in at the last minute, resulting in breakage on the consumer side ** The provider API may break backward compatibility, resulting in breakage on the consumer Instead, what if we could make the dependencies between the provider and consumers explicit in the form of executable contracts. These executable contracts provide a common, clear definition of their API endpoints. They give instantaneous feedback about accidental breakage to the teams so that they can work independently. These executable contracts are: 1. Kept up-to-date and acts as a single source of truth 2. Used for service virtualisation, keeping consumers in sync with the contract 3. Run as tests against the provider API to validate it's request and response type definitions 4. Tightly integrated with CI 5. Capable of pinpointing any backwards-incompatible changes to the contract 6. This is Contract Driven Development, and it heralds the Death of Integration Hell. This session will demonstrate all the key points of Contract Driven Development as implemented by the teams using an open-source tool called Qontract: https://qontract.run/
Empfohlen
Weitere ähnliche Inhalte
Mehr von Naresh Jain
Mehr von Naresh Jain (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Contract Driven Development: The Death of Integration Hell
- 1. Contract Driven Development The Death of Integration Hell 👿 Naresh Jain (@nashjain) https://xnsio.com Release under CC by Naresh Jain @ Xnsio 1
- 2. Micro-Frontends Micro-Services Logical E-Com Application Architecture External Dependencies Payment Service Payment Gateways Authentication Payment Elastic Search DB Inventory & Warehouse Management Systems Product Catalog Service Product Listing Order Management Service Cart DB APIGateway Release under CC by Naresh Jain @ Xnsio 2
- 3. Common SITCommon SIT Current State of Testing in Competitor’s Org PCS OMS PS CS IS SS External Services 1 2 3 Pre-Prod PCS OMS PS CS IS SS 1 2 3 API Testing Workflow Testing E2E Functional Testing Business Acceptance E-Com Store Dev Services PCS OMS PS Warehouse MS Dev Services CS IS SS 1 2 3 Legend Unstable / Down Integration Issue Blocked UnitTesting–Local Prod Release under CC by Naresh Jain @ Xnsio 3
- 5. Project B EATWarehouse MS EATWarehouse MS Dev Services E-Com Store Dev Services Early Feedback in a Controlled Env Common SIT PCS OMS PS CS IS SS PCS OMS PS CS IS SS 1 2 3 External Services 1 2 3 E-Com Store EAT PCS OMS PS CS IS SS Stubbed Dependencies Stubbed Dependencies API Testing Workflow Testing E2E Functional Testing Shift Left Legend Unstable / Down Integration Issue Blocked To Pre-Prod Workflow Testing Release under CC by Naresh Jain @ Xnsio 19
- 6. OMS PCSConnections Tested – 1. Between Internal and External Services 2. Between internal services 3. Between internal units / modules within each service PaymentCart Product ListingSystem Tests Orders Controller Order Repository Product Repository Products Controller SIT PaymentCartOMS Orders Controller Order Repository PCS Product Repository Products Controller Eg: Mockito Eg: Moq Eg: Jest Unit Tests 1. Units / Modules Tested in Isolation 2. System Under Test – Modules 1, 2, 3 and 4 3. Dependencies stubbed with Mock Objects like Mockito, etc. Connections Tested – None Product Listing Local Application Test Pyramid Contractual Stubs PGPCS OMS Orders Controller Order Repository Contractual Stubs DB PCS PCS Product Repository Products Controller Contractual Stubs OMS Elastic Search Component / Service Tests 1. Each Microservice (OMS & PCS) and Micro-frontend (Cart & Payment) tested in Isolation 2. Dependencies (External and Internal) stubbed 3. Negative Path Testing by simulating internal and external dependency errors Connections Tested – Between internal units / modules within each service/component PaymentCart Product Listing Dev Auth OMS PCS Application Tests Only External Dependencies are Stubbed Connections Tested – 1. Between internal services 2. Between internal units / modules within each service Contractual Stubs PG PaymentCart Product Listing Orders Controller Order Repository Product Repository Products Controller EAT Auth Payment Gateway Payment Gateway (PG) Authentication External Dependencies Contract Testing - Turn your contracts into executable specifications Micro FrontendsMicro Services OMS – Order Management Service | PCS – Product Catalogue ServiceRelease under CC by Naresh Jain @ Xnsio 20
- 7. Production Shadow Mode Tests Product Test Pyramid SIT EAT Dev Local Application Tests Component / Service Test Unit Tests System Tests Application 2 Application Tests Component / Service Test Unit Tests System Tests Application 1 Pre-Prod User Acceptance Testing Performance Testing Product Release under CC by Naresh Jain @ Xnsio 21
- 8. Are you sure, this will solve Integration Hell? 2 2
- 9. What’s the main problem you’ve faced with these Mocking Framework? Release under CC by Naresh Jain @ Xnsio 23
- 10. 24
- 11. OMS PCSConnections Tested – 1. Between Internal and External Services 2. Between internal services 3. Between internal units / modules within each service PaymentCart Product ListingSystem Tests Orders Controller Order Repository Product Repository Products Controller SIT PaymentCartOMS Orders Controller Order Repository PCS Product Repository Products Controller Eg: Mockito Eg: Moq Eg: Jest Unit Tests 1. Units / Modules Tested in Isolation 2. System Under Test – Modules 1, 2, 3 and 4 3. Dependencies stubbed with Mock Objects like Mockito, etc. Connections Tested – None Product Listing Local Application Test Pyramid Contractual Stubs PGPCS OMS Orders Controller Order Repository Contractual Stubs DB PCS PCS Product Repository Products Controller Contractual Stubs OMS Elastic Search Component / Service Tests 1. Each Microservice (OMS & PCS) and Micro-frontend (Cart & Payment) tested in Isolation 2. Dependencies (External and Internal) stubbed 3. Negative Path Testing by simulating internal and external dependency errors Connections Tested – Between internal units / modules within each service/component PaymentCart Product Listing Dev Auth OMS PCS Application Tests Only External Dependencies are Stubbed Connections Tested – 1. Between internal services 2. Between internal units / modules within each service Contractual Stubs PG PaymentCart Product Listing Orders Controller Order Repository Product Repository Products Controller EAT Auth Payment Gateway Payment Gateway (PG) Authentication External Dependencies Contract Testing - Turn your contracts into executable specifications Micro FrontendsMicro Services OMS – Order Management Service | PCS – Product Catalogue ServiceRelease under CC by Naresh Jain @ Xnsio 25
- 12. Contract Driven Development Collaboratively Design and Independently Deploy MicroServices & MicroFrontends Release under CC by Naresh Jain @ Xnsio 26 Contract Testing - Turn your contracts into executable specifications
- 13. Collaborative Contract Authoring Release under CC by Naresh Jain @ Xnsio 27
- 14. Contract in central Repo Contracts are executable specs which are version controlled just like code Release under CC by Naresh Jain @ Xnsio 28
- 15. Contract as Test Providers runs these specs as contract tests against their service Release under CC by Naresh Jain @ Xnsio 29
- 16. Contract for Intelligent Service Virtualisation Consumers runs these specs as stubs which validate their expectations Release under CC by Naresh Jain @ Xnsio 30
- 17. Wrapping up 3 Key Takeaways… Release under CC by Naresh Jain @ Xnsio 31
- 18. Takeaway 1: Hyper Collaborate Architect Consumer Dev Provider Dev QA • Collaboratively design the API over a contract • Communicate with a common language Release under CC by Naresh Jain @ Xnsio 32
- 19. Takeaway 2: Shift Left Consumer Provider Stub Test • Identify integration issues early • local development environment • CI • Develop with ease CI Pipeline Environment Release under CC by Naresh Jain @ Xnsio 33 Contract
- 20. Takeaway 3: Deploy With Confidence • Deploy independently, with confidence • Bye-bye, Integration Hell! Higher Environment Release under CC by Naresh Jain @ Xnsio 34
- 21. Release under CC by Naresh Jain @ Xnsio 35 https://qontract.run
- 22. Thank you! Naresh Jain (@nashjain) https://qontract.run Release under CC by Naresh Jain @ Xnsio 36