Contributing to Ecotone

Preparing development environment
Start by cloning ecotone-dev repository. 
1.To run your local environment with tests:
2.Copy .env.dist to .env and start docker containers
docker-compose up -d
3.To run tests for monorepo:
docker exec -it ecotone_development composer tests:local
4.To run tests for given module
docker exec -it -w=/data/app/packages/Dbal ecotone_development composer tests:ci
5.Clear development environment
docker-compose down
Debugging code
Development containers comes with xdebug installed, so you can debug directly from IDE.
To have enabled debugging all the time, change line in your .env file to 
XDEBUG_ENABLED="1"
and rebuild containers:
docker-compose down && docker-compose up -d
As having xdebug enabled all the time, may slow your test execution, you may run it conditionally for given test case
docker exec -it ecotone_development xdebug vendor/bin/phpunit --filter test_calling_command_on_aggregate_and_receiving_aggregate_instance
If you're asked about mapping path, map your xdebug server to "/data/app" and name it "project", if you have not changed xdebug project name.
Ecotone Concepts
Even though Ecotone introduces its own concepts, many of them already existed. A good source of information is Gregor Hohpe's Enterprise Integration Patterns website and accompanying book.
For example, if you're interested in what Service Activator is, you make take a look here.​
You may also take a look on previous chapters to get familiar with fundamental building blocks.
Due to the fact that Ecotone is based on EIP patterns, you will find a lot of similarities to well known frameworks in other languages, like C#'s NServiceBus or Java's Spring Integration (which is foundation for Spring Cloud), as they are also built on top of EIP patterns.
Contribution guidelines
Make use of real providers in tests - This means, if integrating with RabbitMQ/SQS write tests that actually make use of this Message Brokers. This will ensure, that tests will stay the same, even if underlying 3rd party library/SDK will change.
Focus on client level code - Your tests do not need to test every single class you add to the repository. It's more valuable from perspective of long term maintenance to focus on tests that will be testing on the high level (using Ecotone Lite). 
Those tests will be also similar to the ones, you will be writing in your own Ecotone based projects.
Ask questions in case you need some help - You can use Ecotone's community channel to get quick feedback and help with your implementation.

Last modified 4mo ago