|
|
|
|
|
by TOGoS
1459 days ago
|
|
I've used a similar system, and tried to formalize this approach at work. The directory containing the projects is the "workspace" or "deployment" (depending if you're talking about your dev machine or a server, but same structure), and it contains "projects". Take whatever set of projects at whatever versions they need, check them out to the workspace, maybe set some environment variables (or symlink apache config files) as applicable, and hit the run button. The biggest downsides of this approach that I discovered are that (A) projects are not self-contained, which meant some expert (i.e. me) always had to go and fix the deployments, because nobody else understood the system, and (B) a lot of the frameworks we used had their own system for organizing dependencies, which meant that we'd end up with projects inside projects inside projects anyway, and this system, whose intended purpose was to _flatten_ the directory tree, effectively just added another level to it. Edit: (C), which is a variation of (B): if some projects are in monorepos, that throws off the system, too. Now instead of workspace/project you have workspace/monorepo-project/subproject, so now in some cases you have to reference "../../something" instead of just "../something".
Not everything fits into the nice flattened-out system where relative paths are easy to guess, so you end up having to either merge things together with symlinks, which gets confusing because now you have two parallel structures going on, or just configuring dependencies with environment variables after all (at which point you wish you had just formalized the environment variables from the beginning to make everything explicit). |
|