Many teams working with microservices need confidence they don't break functionality when making changes. System integration tests, functional tests, and sometimes manual tests are older ways to obtain that confidence. These processes may take more than 1 day or even more if different teams or a different company own the services.

To ensure the same level of confidence and speed up delivery, we can create Contracts for integrations between consumers and providers. Contracts created by consumer services need to pass with every build going in production to guarantee the integrations between systems/services work fine. Checking these contracts in a CI/CD pipeline makes feedback loops even faster.

A Contract is a collection of agreements between a Consumer and a Provider that describes the interactions that can take place between them. Consumer Driven Contracts (CDCs) is a pattern that drives the development of the Providers from its Consumer's point of view. It is TDD for microservices.

This talk covers an end to end demo of contract testing between two microservices to show how to release microservices with confidence, get early feedback, speed up delivery, and comparison with other testing strategies.

Happy CDC!

Agile Principle # 12 defines that at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. From Scrum to Kanban and other agile frameworks, this is accomplished through retrospectives and continuous improvement processes. The key to being a successful agile practitioner is to identify areas of improvement and then experiment ways of improving it. But it doesn't stop there; positive improvements ultimately become success stories for other teams and motivates them to experiment with newer ideas which eventually leads to innovation. A negative outcome isn't bad either since it adds to the experience of situations where ideas may not apply. Thus the key to this process lies in being a child, an explorer, and inculcate an experimentation mindset. The SLICE framework addresses this in the following way:

• S hare: Share an area of improvement
• L earn: Explore the area for ways of improvement
• I mplement: Search & apply the learning to identify the success factors
• C ollateral: Publish blogs, white papers, presentations, etc. as observations of the implementation
• E xpansion: Grow, Seed, and Split in order to explore new venues for success

In this talk, I create an environment that inculcates an experimentation mindset and utilise the SLICE framework to drive the exploration.

When agile came into being, a lot of the new technologies that we know today did not even exist. Does our definition of agile and the process that we follow change with new areas of technology thinking like data science, artificial intelligence & big data engineering coming into picture? Does INVEST make sense for data stories? Do we even write stories or should we work hypotheses instead? Do we need Acceptance Criteria or Exit criteria? How do lean, agile & product principles work in context of AI problems? What happens when science meets products?