With only a single command the MicroDocs CLI can setup all the Microservices you need to
start developing.Example: The following command starts the customer-service and all its depending services
in Docker.
mdocs up customer-service

Everyone breaks an API contract once in a while.
With MicroDocs you can check if you are about to make breaking changes while still in your IDE.
There are verious plugins for build tools which adds a task to check for breaking changes.

In Pull Requests it's sometimes hard to see if someone is about to Break an API contract.
MicroDocs adds a plugin to Jenkins which can check for breaking changes in a Pull Request.
Problems can then be posted as comments back into the Pull Request in BitBucket.

The power of MicroDocs are the definitions of the MicroServices. It's like the metadata of each service.
The definitions should therefore follow the flow of the Docker images.
Each definition has a version which corresponds with the Docker image.
Like the Docker registry, definitions should be published to the MicroDocs Server.
Through the pipeline the definitions can be promoted to different environments (develop/test/staging/production).

To setup a working test environment with the right services and versions can sometimes be hard.
MicroDocs can create a deployment configuration to startup a single Microservice with its depending services
or a deployment configuration for a whole cluster.

Just like with the Test environment setup, a deployment configuration can be created to deploy your Microservices to production.
Where each service will be routed to a version of a depending service which is known to be working.
So you won't have breaking changes anymore in production.