Home

The problem

Microservices are really great especially when done with frequent delivery. But frequent delivery is not easy. One of the key ingredients is deployment pipeline which you can trust. I mean, when a change you've just made goes through deployment pipeline and passes series tests (unit, integration, e2e) you're SURE you can deploy to PROD.

But the question is: How do you know it will still work on PROD?

I can tell you this: it's not a question easy to answer. Sure, there are things which easily verifiable like will it start. But there are others not that easy: Will it be able to talk to other services (did I make a type in that DTO representing the response comming from other service), Will other services be able to talk this this one I've just changed (maybe accidentally I've changed the endpoint name)

To answer this question and increase your level of confidence you can check two things:

1. what this newly build version of your service expects from other services and
2. what other services from PROD expect from your service

in other words: compare capabilities of you service with expectations of its consumers

or in yet another words: do contract testing but a kind that's environment aware. This is exactly what Judge-D gives you.

The solution

Judge-D stores

1. composition of an environment (all available services with version)
2. for each service: its capabilities and expectations towards other services

with the above in place all you need to do is build your service, generate capabilities (e.g. swagger for rest) and expectations (e.g. pact files for rest) and upload them to Judge-D. It will immediately tell you if your newly build service is compatible with the whole environment.

How it works

// TODO: add a diagram with environment, jenkins, judge-d, judge-d-agent and a report