There is a main application, let's call it APP.
APP has several dependencies (including open source projects and proprietary libraries).
There are multiple clients that use their own instance of APP (on different domains that I manage). Some of these clients use a slightly adjusted version of APP. I implemented this by creating a specific module (let's call it SM) for each client that I just add to their instance of APP (so that I don't change any of the code from APP).
Currently, I've implemented this as follows:
Develop APP locally, use Composer to update its dependencies (
composer update
),push
APP on central repoFor each regular client,
pull
APP from central repo and install the Composer dependencies (composer install
)-
For clients with specific implementation, create a new SM (specific module), that has the following
composer.json
file:... "require": { "APP": "X.X.X" } ...
Then apply the same steps as before for this SM (composer update
locally, PUSH
to central repo, PULL
from central repo, composer install
).
Everything is fine, except for two issues that I'd like to overcome:
composer.lock
from APP will be ignored by SM (since APP is loaded as a library in thevendor/
folder, and composer ignores thecomposer.lock
files of libraries); this is not good at all, as I will not be confident that the specific clients will use the exact same libraries as APP.Each time I fix a bug or implement a new feature in APP (and this happens frequently - a few times a day), apart from the steps that I perform for the regular clients, I also need to rebuild the SMs (since one of their libraries - APP - was updated to a new version that I need to use). This is an overhead since most of the changes that I perform are inside APP (and not SM). So, if it was the other way (APP having SM as a dependency), it would have been working faster (since I wouldn't need to
composer update
on each SM).
Are there any known workflows or best practices that cover this scenario in order to mitigate the two issues above or at least to decrease the complexity of the upgrade/deployment process?
Please note that most of the steps above are already automated, so my question is not about the automation part, but the complexity of this architecture