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:
- Contract Test
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
- Intelligent Service Virtualization
Specification Editor and plugin in
- Central Contract Repo
with pull/merge request process to enforce necessary backward compatibility checks and linting to ensure high quality specs.
Programming Languages
- Continuous Integration
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
- Representative Functionality
Select a functionality that cuts across your view.js front-end and Spring Boot backend as a representative functionality of your technology stack.
- Multiple Dependencies​
Backend service should have one or more http service dependencies, database dependency, etc. so that we can demonstrate all the concepts clearly.
- Keep It Simple​
Not overly complex so we can ensure we are able to complete the POC within the stipulated timebox.
POC Programme overview
Our hosts
Naresh Jain
Joel Rosario
Hari Krishnan
Jaydeep Kulkarni
2 Week Overview
Day 1Basic Setup
- 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
Day 2Get a single interaction/route contract tested and stubbed
- 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
Day 3Central contract repository setup
- 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
Day 4 & 5Complete CDD on pending routes
- 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
Day 6API specification cleanup
- 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
Day 7Application resiliency analysis
- Provider – Analyze Specmatic generative test failures and prepare detailed report
- Consumer – Fault simulation (empty & error state, timeouts, etc.) with Specmatic stub
Day 8Asynchronous interactions
- 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
Day 9Storage stubbing with Specmatic
- Examples: Redis, JDBC, etc. wire compatible stubbing to improve isolation of application in local and CI while running tests
Day 10Demo to all stakeholders
- 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