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.

Increased Pace​

Embrace parallel development, slash cycle times, and deliver products to market faster than ever before.

Enhanced Confidence​

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

In-Depth Understanding

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 Standards

ASync API logo
OpenAPI logo
of the provider using the same OpenAPI spec, so that we can component test the consumer.

Specification Editor and plugin in

Swagger logo

with pull/merge request process to enforce necessary backward compatibility checks and linting to ensure high quality specs.

Programming Languages

Java logo
JavaScript logo
TypeScript logo
Python logo

pipelines setup with hard-gates on provider, consumer and central contract repo.

CDD

Linting

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

Our hosts

Joel Rosario

Co-founder, Chief Scientist

Jaydeep Kulkarni

Principal Architect

Hari Krishnan

Co-founder, CTO

Week 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
  • Provider
    • Run the specification for that route as a test on the Provider on local machine
    • Run generative tests and observe any breakages
  • Consumer
    • 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

Sign Up for a 2-Week POC Consultation