带有作曲家的多个应用程序

Question

有一个主应用，姑且称之为APP吧。

APP有几个依赖项（包括开源项目和专有库）。

有多个客户端使用他们自己的 APP 实例（在我管理的不同域上）。其中一些客户端使用的APP版本略有调整。我通过为每个客户端创建一个特定的模块（让我们称之为 SM）来实现这一点，我只是将其添加到他们的 APP 实例中（这样我就不会更改 APP 中的任何代码）。

目前，我实现如下：

本地开发APP，使用Composer更新其依赖(composer update)，push中央仓库上的APP
对于每个常规客户端，pull 来自中央仓库的 APP 并安装 Composer 依赖项 (composer install)
对于具有特定实现的客户端，创建一个新的 SM（特定模块），其中包含以下 composer.json 文件：
```
...
"require": {
    "APP": "X.X.X"
} 
...
```

然后对该 SM 应用与之前相同的步骤（composer update 在本地，PUSH 到中央仓库，PULL 来自中央仓库，composer install）。

一切都很好，除了两个我想克服的问题：

composer.lock 将被 SM 忽略（因为 APP 作为库加载在 vendor/ 文件夹中，而 composer 忽略 composer.lock 文件库）；这一点都不好，因为我不确定特定的客户端是否会使用与 APP 完全相同的库。
每次我在 APP 中修复错误或实现新功能时（这种情况经常发生 - 一天几次），除了我为普通客户执行的步骤外，我还需要重建 SM（因为他们的一个库 - APP - 已更新到我需要使用的新版本）。这是一项开销，因为我执行的大部分更改都在 APP（而不是 SM）内。所以，如果它是另一种方式（APP 有 SM 作为依赖项），它会工作得更快（因为我不需要在每个 SM 上 composer update）。

是否有任何已知的工作流程或最佳实践涵盖此场景以缓解上述两个问题或至少降低 upgrade/deployment 流程的复杂性？

请注意，上面的大部分步骤已经自动化，所以我的问题不是关于自动化部分，而是这个架构的复杂性

Answer 1

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

For clients with specific implementation, create a new SM (specific module), that has the following composer.json file:

这是一个带有客户端特定模块的应用程序（在其他依赖项旁边）。

应用程序有模块作为依赖（APP有SM作为依赖）。

而不是：模块拉取应用程序，因为它是供应商依赖项。这只会导致在开发阶段（您的问题 2）采取额外的步骤。

我建议重构应用程序及其模块，直到您获得以下文件夹结构：

|-application             #< the application has dependencies
  |-src
  |-tests
  |-vendor
    |-framework           #< maybe your application is framework based
    |-libs                #< more dependencies
    |-...                 #< other modules
    |-sm                  #< the client specific module

这允许引入依赖项，扩展“应用程序”以满足客户特定的需求。

这解决了问题 1，因为 APP 是主存储库并包含锁定文件。必须锁定版本，以便所有开发人员都绑定到相同的版本，并且还可以打包完全相同的一组版本。

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).

是的！如果您开始使用模块依赖项“在 APP 内部开发”，则每次更改 APP 时都不需要重建模块。

对于多个客户端，只需使用具有一组自定义要求的多个应用程序存储库即可。 10 个客户端，10 个应用程序存储库，10 个 composer.json 文件。运行 composer install no-dev 然后预先打包每个 repo 并将 zip 放入下载。完成。

您可以在此处使用“容器”或“打包”项目，其中每个项目的 composer.json 将包括应用程序和特定模块。您可以使用脱字符号或波浪号运算符来指定应用程序的版本范围 ("vendor/app": "^1.2.3")，然后在应用程序的新版本发布后简单地使用 update 和 repackage。这种方法应该适用于 composer 自动加载，因为应用程序也将保留在 vendor 文件夹中。只需要一点包装器，即可设置 composer 自动加载器并切换到您的应用程序。

或者，如果应用程序真的是模块化的。只需打包主应用程序并提供特定于客户端的模块作为额外下载。使用这种方法升级将有多个下载步骤：升级应用程序、升级模块。将其视为“wordpress 风格”updates/upgrades.

您可以通过在客户端计算机上删除 composer install --no-dev 部分来进一步降低 upgrade/deployment 过程的复杂性通过在开发人员机器上构建“特定于客户的应用程序档案”。这些基本上是应用程序的“--no-dev”包及其所有依赖项，包括客户端特定模块 = 预打包。

喜欢，Application-v1.2.3-WithModuleAForClientA-v3.2.1.zip。

在开发机器上：composer install --no-dev --optimize-autoloader + zip.

要简单地安装或升级 download 客户端，extract，执行 upgrade 脚本。完成。

带有作曲家的多个应用程序

Multiple apps with composer

php

deployment

frameworks

composer-php