mybuilder / Conductor
Labels
Projects that are alternatives of or similar to Conductor
We no longer use Conductor at MyBuilder and instead now use the Composer path but if you want to take over development of Conductor let us know.
This tool allows you to manage isolated, internal Composer packages within a single, monolithic repository. Separating units of code based on directory structure, as opposed to at the repository level, maintains a single source of truth whilst providing the benefits of clearly defined component boundaries.
When would you use it?
You would use this tool in a project setting where multiple separate applications co-exist (i.e. admin, frontend and mobile-api). Within this context each application will share code, such as business logic, to provide the end solution.
An example project repository structure that we use in-kind is shown below:
├── app/
│ ├── admin
│ │ ├── src/
│ │ ├── tests/
│ │ └── composer.json
│ ├── frontend
│ │ ├── src/
│ │ ├── tests/
│ │ └── composer.json
│ └── mobile-api
│ ├── src/
│ ├── tests/
│ └── composer.json
├── artifact/
├── bin
│ └── conductor
├── package
│ ├── bar
│ │ ├── src/
│ │ ├── tests/
│ │ └── composer.json
│ └── foo
│ ├── src/
│ ├── tests/
│ └── composer.json
├── composer.json
└── conductor.yml
As you can see the root-level composer.json file is only used for uniform tooling - so no project specific code should be stored at this level. The business logic is contained within each of the isolated packages, with the delivery supplied via the 'app' directory.
Compatibility
- ✔ Mac OSX
- ✔ Unix-derived systems (CentOS, Debian etc.)
- ? Windows - Not tested at this time
Examples
At this time the project comes with a simple todo example which illustrates how to use Conductor in it's entirety.
Further Reading
Created by MyBuilder - Check out our blog for more insight into this and other open-source projects we release.