Discover the benefits of CDD in your organization
Embrace CDD with confidence. Our 2-week Proof of Concept lets you experience how it fits your business, removes bottlenecks, and accelerates your time to market.
Here's what your business will gain
The consultation aims to address any questions while demonstrating the potential of independent development and deployment with CDD to empower your business to achieve faster, more confident, and efficient software development practices.
Embrace parallel development, slash cycle times, and deliver products to market faster than ever before.
Integration issues are minimized as the project goes through integration testing, ensuring a smoother and more reliable process.
Ease of Implementation
Our Proof of Concept simplifies the process, allowing you to grasp CDD’s implementation intricacies with ease
Our hands-on experience equips your business with insights to navigate the world of Contract Driven Development effectively
What we offer
A proof-of-concept implementation of CDD, at both a code and practice level. Over 2 weeks (10 working days) your team will be guided through the fundamentals of implementing CDD. This includes:
the provider using their OpenAPI Spec and stubbing out provider’s dependencies using OpenAPI or AsyncAPI specs of the dependent services. Also, if required we can stub out Redis, ElasticSearch and database via JDBC.
Specification Editor and plugin in
with pull/merge request process to enforce necessary backward compatibility checks and linting to ensure high quality specs.
pipelines setup with hard-gates on provider, consumer and central contract repo.
What will you need to get started?
Definition of Ready: a few components / services / APIs that are representative of your overall technology stack. A few members of your team (part time) who are SMEs on these services to help drive the proof of concept with us.
Criteria for selection of components and services
Select a functionality that cuts across your view.js front-end and Spring Boot backend as a representative functionality of your technology stack.
Backend service should have one or more http service dependencies, database dependency, etc. so that we can demonstrate all the concepts clearly.
Not overly complex so we can ensure we are able to complete the POC within the stipulated timebox.
POC Programme overview
- Get applications running locally with / without mocking dependencies
- Complete functional overview and rough architecture diagrams
- Get applications running on local machine
- Isolate dependencies – Dockerise, In-memory DB, Queues, etc.
- Switch off cross cutting concerns – Authentication, Caching, etc.
- Automated inventory of routes, routes in API specifications, correctness of API specifications with actuator integration
- CI pipelines and version control overview
- Record observations, challenges faced
- Select a route that has API specification / can be generated with Specmatic
- Run the specification for that route as a test on the Provider on local machine
- Run generative tests and observe any breakages
- Run existing UI Component Test / Write one for the related interaction
- Stub the backend with the same API specification that was run as contract test
- Attempt running both of the above test setup on their respective CI pipelines
- Create a fresh Git Repository
- Push the API specification we used above into this repository
- Reference the same on both Consumer / FE and Provider / BE applications and make sure they are working in CI pipeline also
- Pre-merge hook setup
- API Specification Linter Setup – Standard OAS ruleset with minor upgrades where necessary
- Specmatic Backward compatibility testing setup
- Merge policies
- Block until linter and backward compatibility pass
- Test the setup with breaking changes in both syntax and content
- Branch policies
- Disallow direct merge to master
- Require minimum number of reviews
- Pre-merge checks to pass
- Generate / Record API specifications with Specmatic
- Review and update the recorded API specifications with respective service owners
- Strive to reach 80% plus branch coverage independently with Contract Tests alone
- Agree on API conventions – naming, response codes, headers, etc.
- Automate the same with Linter that we setup earlier on central contract repository with custom rules
- Take stock of API design improvements
- Provider – Analyze Specmatic generative test failures and prepare detailed report
- Consumer – Fault simulation (empty & error state, timeouts, etc.) with Specmatic stub
- Analyze asynchronous interaction such as Kafka, JMS, etc.
- Stub these with Specmatic AsyncAPI support to verify schema compatibility and more
- Run the AsyncAPI specifications as test where application
- Examples: Redis, JDBC, etc. wire compatible stubbing to improve isolation of application in local and CI while running tests
- Detailed demo with your team members themselves presenting the work they have been able to do
- Specmatic team sharing their observations and recommendations with detailed action plans
- Decide on next steps