Skip to content

Latest commit

 

History

History
97 lines (61 loc) · 4.06 KB

CONTRIBUTING.md

File metadata and controls

97 lines (61 loc) · 4.06 KB
Raw

Contributor

😍 Thanks for taking the time to contribute! You're awesome! 😍

There is a tons of helpers availables through a Makefile, just type make list

In addition of usage requirements you need to install dot to be able to print the workflow.

For test purpose you need several additional databases, you have to fill their information on tests/test_config.yml:

Please run CS-fixer, PHPSpec and PHPUnit before committing. (make commit if you want to use the Makefile)

  $ php ./vendor/bin/php-cs-fixer fix --config=./.php_cs.php
  $ php ./vendor/bin/phpspec run
  $ php ./vendor/bin/phpunit

If you have updated the workflow, please update the generated graph:

  $ php Transporteo.php state-machine:dump
  $ dot -Tpng stateMachineTransporteo.dot -o stateMachineTransporteo.png

HOW IT WORKS BEHIND THE SCENE

This project tries to respect Ports and Adapters Architecture, if you want to discover more about that, you can check these links (by Alistair Cockburn (inventor of the concept)

Concretly, our ports for us are in the Domain layer meanwhile Adapters are in the Infrastructure layer.

Each steps is represented as a folder in Domain

The State Machine

Transporteo is like managing a whole state of a migration processus, this is the only thing that the tool is able to do: Migrate.

So, the whole software is a state machine that goes from one state/step to another.

What is a state machine?

A state machine can be seen as a directed graph like a workflow, edges are called "Transitions" and node are called "States". A state is a state, nothing is happening when a state is marked.

It is only during transitions (so from one state to another) that something can happen.

A state machine can only handle one state at a time but you can have several transitions availables from one state. To make a choice, there is a system called a "guard". A guard is the responsability of a transition to accept or not to be crossed.

To be able to implement quickly a state-machine pattern, The Symfony's workflow component has been choosed to benefits from the Symfony environment which is well known at Akeneo.

Some links to understand how works the Symfony Workflow component

The TransporteoStateMachine is the object handled by the state machine but also the state machine itself. Indeed, this state machine is able to go from one step to another directly and so it is also where all the context information gathered during the migration process are stored.

We differentiate business steps and technical steps in the state machine and the way we created our class to listen to workflow events have been created reflects business steps like "FromDestinationPimStructureMigratedToDestinationPimFamilyMigrated".

The dependency injection

The dependency injection is also handled by Symfony with the usage of their new features the "autowiring" and "autoconfigure"

The container is build in ContainerBuilder.php

Here is some links to understand and see how it works Symfony Framework is not used in this project:

Source Pim and Destination Pim management

Source Pim designates the Pim we want to migrate from and Destination Pim designates the Pim we want to migrate to.

For development purpose both Pim are installed locally with Mysql 5.7 but the goal is to have several possible locations.

For the SourcePim:

  • Locally
  • On Server (through SSH)

For the Destination Pim:

  • Locally

The rule is : "THE SOURCE PIM SHOULD NEVER BE TOUCHED".