后面这个多个 composer.json 的方案很巧妙，曾经做的时候，都是在开发阶段单独弄个分支去写 repositories 信息，要合并主干时再处理。

mark一下，碰到同样的问题

先说一下我们目前实现的方案吧

我们没有考虑太多CI/CD的问题，这里有些路径依赖，团队技术演进的方向一直没有太侧重这方面，也有些许成本的问题。所以生产环境和测试环境的差异较大，开发环境则因人而异。这样的缺点是很明显的，但与楼主的主题关系不大。

采用 composer.json 来管理扩展包

    "repositories": {
        "packagist": {
            "type": "composer",
            "url": "https://mirrors.aliyun.com/composer/"
        },
        "kdd/module-coupon": {
            "type": "vcs",
            "url": "git@xxx.com/kdd-module-coupon-sihui.git"
        },
        "kdd/deploy-sihui": {
            "type": "vcs",
            "url": "git@xxx.com/kdd-deploy-sihui.git"
        },

和楼主采用的方案一样，我们也是通过 repositories 来引入自己的扩展包，只不过我们懒得自己搭 git 服务，所以直接使用了 coding.net 提供的私有仓库。功能上很齐全，还能跟他提供项目协同、文档、测试用例和持续集成功能结合起来用。访问仓库之际使用秘钥对即可。

由于我们采用的是 docker 镜像构建的发布方式，拉取代码时需要将可以访问仓库的私钥配置到凭证里面，并在构建时还原私钥。构建完成会直接将镜像推送到 coding 的制品库(有很多种类，docker镜像仓库是其中之一)。

pipeline {
  agent any
  stages {
    stage('检出deploy-sihui') {
      steps {
        checkout([$class: 'GitSCM',
        branches: [[name: GIT_BUILD_REF_DEPLOY]],
        userRemoteConfigs: [[
          url: GIT_REPO_URL_DEPLOY,
          credentialsId: CREDENTIALS_ID
        ]]])
        sh '''mkdir /root/deploy
cp composer/composer.json /root/deploy/'''
      }
    }

    stage('检出sihui-kernel') {
      steps {
        checkout([$class: 'GitSCM',
        branches: [[name: GIT_BUILD_REF]],
        userRemoteConfigs: [[
          url: GIT_REPO_URL,
          credentialsId: CREDENTIALS_ID
        ]]])
        sh 'cp /root/deploy/composer.json ./'
      }
    }

    stage('构建镜像并推送到 CODING Docker 制品库') {
      steps {
        // 限于篇幅，不做展开
      }
    }

  }
  environment {
    // 限于篇幅，不做展开
  }
}

从以上 jenkinsfile 内容可能看不太出来，但其实代码仓库访问分为三部分，这里能看到对主项目代码仓库的访问和特殊的 deploy 分包的代码仓库访问（这个分包类似胶水，作用是协调分包和主项目之间的配置数据），另一部分其实实在 Dockerfile 里面来进行呈现。

# composer 
FROM composer:2.1.6 as composer
# 私钥文件参数
ARG id_rsa=id_rsa
COPY database/ /app/database/
COPY composer.json /app/
RUN mkdir /root/.ssh
ADD ${id_rsa} /root/.ssh/id_rsa
ARG CACHEFIX=cachefix
RUN touch /root/.ssh/known_hosts \
    && chmod -R 0600 /root/.ssh \
    && ssh-keyscan xxx.net >> /root/.ssh/known_hosts \
    && composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ \
    && cd /app \
    && composer update \
           --optimize-autoloader \
           --ignore-platform-reqs \
           --prefer-dist \
           --no-interaction \
           --no-plugins \
           --no-scripts \
           --no-dev

# laravel
# FROM xxx.com/php:php8-1.3
FROM xxx.net/kdd/php:php8-1.3
ARG LARAVEL_PATH=/www/wwwroot
WORKDIR ${LARAVEL_PATH}

COPY . ${LARAVEL_PATH}
COPY --from=composer /app/vendor/ ${LARAVEL_PATH}/vendor/
COPY docker/entrypoint.sh /usr/local/bin/entrypoint
RUN cd ${LARAVEL_PATH} \
    && cp config/php.ini /usr/local/etc/php/php.ini \
    && php artisan package:discover \
    && chown -R www-data:www-data . \
    && chmod -R +x . \
    && chmod -R 0766 storage \
    && chmod +x /usr/local/bin/entrypoint \
    && cp crontab /var/spool/cron/crontabs/root \
    && crontab /var/spool/cron/crontabs/root \
    && rm id_rsa
STOPSIGNAL SIGTERM
ENTRYPOINT ["/usr/local/bin/entrypoint"]

注意这个 composer 镜像的版本很重要，升级之后将无法使用私钥，我也不知道原因，还请知情的小伙伴不吝赐教。

Dockerfile 分为两部分，第一步就是通过 composer.json 获取全部分包文件，包括咱们自己开发的。第二部分则是将主项目和分包的vendoer目录拷贝到基础镜像。

测试环境为了便于测试和研发工程师去快速调整环境，采用了与基础镜像同源的镜像挂载分包和主项目路径通过 docker-compose 进行编排部署。生产环境则使用 Kubernetes 编排部署，环境差异还是挺大的，但测试环境用不起集群呀（捂脸）。

篇幅有点长，发不出来，这里接上贴

为什么要分包

我们分包的意义在于复用逻辑，由于要考虑为不同的客户（包括我们自己）部署系统，所以需要将公用逻辑放到主项目中，容易产生差异的逻辑放到分包中。客户之间的需求差异，我们可以采用不同分包进行适配，可以使用分包中不同的版本标签来保证分包在不同项目中运行的稳定性。

再说说我们的问题

composer update

可以从 Dockerfile 中发现，我们执行的是 composer update 来进行镜像构建的，这样做肯定会造成各个环境中非自研分包的版本差异。为什么要这样做，请听我诡辩：

不同客户需求的分包和版本都不同，所以 composer.json和composer.lock 都不能简单进入代码仓库。我们选择使用一个特殊的 deploy 分包来保存不同客户项目之间的差异，也包括 composer.json 文件。不保存 composer.lock 文件的主要原因是因为对该文件的编辑太频繁了，每次提测发布都要想着重新生成该文件到deploy分包里，我们直接做了简化处理。

分包逻辑编排

分包和主项目之间，分包与分包之间的编排，我们提到了特殊的 deploy 分包。他无法在不同客户的项目中复用，他主要提供的能力主要有两点：

1. 维护 composer.json 文件差异，这决定了不同项目都有哪些功能差异；
2. 保存项目间差异的配置参数；

第一点很容易理解，第二点则可以参考管道模式来理解。分包与主项目，分包与分包之间的逻辑编排，被保存到配置数据中，然后通过管道模式进行调用。

我们直接看样例，比如主项目中注册一个管道入口：

            pipeline()->through(config('pipes.inventory.sku_shop.inventory_handle.update_before', []))
                ->send([
                    'data' => $data,
                    'service' => $this,
                ])
                ->via('updateBefore')
                ->thenReturn();

deploy 分包则有个配置文件 config/pipes/inventory.php

return [
    'sku_shop' => [
        // 库存处理
        'inventory_handle' => [
            // 库存更新之前
            'update_before' => [
                   \Kdd\Module\Xxx\Pipes\Inventory\UpdateBefore::class,
            ],
        ],
    ],
];

对应的 kdd/module-Xxx 分包的逻辑就会被编排进来执行 src/Pipes/Inventory/UpdateBefore.php

namespace Kdd\Module\Xxx\Pipes\Inventory;

use Closure;

class UpdateBefore
{
    /**
     * @param array $passable
     * @param Closure $next
     * @return mixed
     */
    public function updateBefore (array $passable, Closure $next)
    {
        $result = $next($passable);
        // 自己的逻辑
        return $result;
    }
}

小结一下

这套模式已经从2020年开始用到现在，虽然也经历过各种问题，但比较契合我们的使用场景，促使我们持续使用到今天。各位小伙伴如果有任何分包的问题和方案欢迎来一起交流。

gitee.com/fresns/plugin-manager

gitee.com/fresns/market-manager

了解一下