你们是如何敏捷开发 Laravel 私有扩展包的？
606 / 18 / 创建于 1年前 /
GeorgeKing 的个人博客
起因
最早之前我们的所有端都是在一个项目中，通过 URL Prefix 来实现区分 C 端和 B 端的不同业务逻辑。虽则业务的扩张，和业务的越发复杂，我们不得不将臃肿的单体应用拆分为面向多个端的项目。
为了方便维护，我们将业务中的核心逻辑如数据模型和本地化语言包等，进行拆分和封装，作为单独的扩展包进行提供。
这样，地产业务逻辑的改动，只需要在一个扩展包项目中进行变更就可以了。
问题
拆是拆了，但是也伴随着一些问题：
- 这个扩展包一定得是私有的，外部无法访问
- 本地开发和测试时如何绕过私有扩展包的发布流程，直接将最新代码应用到本地和测试环境
- 在 CI/CD 中如何实现自动区分环境来安装不同来源的包
为了解决上述问题，我们也是调研了很久，最终选定了如下技术作为解决方案：
- Gitlab
- Gitlab-Runner
- Deployer
解决方案
第一个问题其实很好解决，Gitlab 本身支持 Composer Package Registry，我们只需要利用 Gitlab CI/CD 将私有扩展包项目的 release 分支通过 API 请求注册到 Gitlab Composer Package Registry 即可！
在我入职前，团队采用的是 vcs 的方式从 Gitlab 拉取，这种方式实现成本最低，但是潜在的问题是会拉取 .git 信息，随着扩展包的 commit 记录越来越多，导致耗费的时间也就越来越长，甚至是 composer install 的时候内存溢出。
发布扩展包
使用如下 Gitlab CI/CD 配置，自动向 Gitlab Composer Package Registry 发布扩展包：
stages:
- staging
- release
staging:
image: betterde/rsync:latest
stage: staging
only:
refs:
- develop
tags:
- backend
script:
- mkdir -p ~/.ssh
- echo "$SSH_PRIVATE_KEY" >> ~/.ssh/id_rsa
- chmod 600 ~/.ssh/id_rsa
# 这里主要是为了在测试环境及时更新 develop 分支的代码，配合 composer 的 path repository 实现从本地加载最新扩展包（目录和分支名称根据实际情况进行替换）
- ssh -p "$SSH_PORT" -o StrictHostKeyChecking=no root@"$PREVIEW_SERVER" "cd $PACKAGE_PATH/harbor && git checkout develop && git pull"
release:
image: betterde/deployer:6.8.0
stage: release
only:
refs:
- tags
tags:
- backend
script:
# 当我们为扩展包打上 Tag 以后，自动触发 Pipeline 向 Gitlab Package 注册扩展包信息。
- 'curl --header "Job-Token: $CI_JOB_TOKEN" --data tag="$CI_COMMIT_REF_NAME" "https://gitlab.example.com/api/v4/projects/$CI_PROJECT_ID/packages/composer"'PACKAGE_PATH 这个环境变量已经在 Package 这个项目组中进行了定义，目录为 /usr/wwwroot/package，你只需要在测试服的这个目录中，克隆扩展包项目，然后切换到开发分支即可。
在生产环境使用
# 这个命令可以在 Gitlab 项目 Package Registry 中获取到。
composer config repositories.<group_id> composer https://gitlab.example.com/api/v4/group/<group_id>/-/packages/composer/执行上述命令后将会在 composer.json 文件中追加如下内容：
{
"repositories": {
"<group_id>": {
"type": "composer",
"url": "https://gitlab.example.com/api/v4/group/<group_id>/-/packages/composer/"
}
}
}配置授权信息：
# 将<GITLAB_DOMAIN>替换为实际的 gitlab 域名
composer config gitlab-domains <GITLAB_DOMAIN>执行玩上述命令后，将会在 composer.json 文件中追加如下内容：
{
"config": {
"gitlab-domains": ["<GITLAB_DOMAIN>"]
}
}然后再执行如下命令：
# 这里的 GITLAB_DOMAIN 需要和前面一致，然后创建你个人的 Gitlab PERSONAL_ACCESS_TOKEN，并替换 PERSONAL_ACCESS_TOKEN
composer config gitlab-token.<GITLAB_DOMAIN> <PERSONAL_ACCESS_TOKEN>执行完上述命令后，会在项目目录下生成 auth.json 配置文件：
{
"gitlab-token": {
"<GITLAB_DOMAIN>": "<PERSONAL_ACCESS_TOKEN>"
}
}到此，私有扩展包的发布和线上安装已经解决了，接下来就是第二个问题，本地开发和测试时如何绕过私有扩展包的发布流程，直接将最新代码应用到本地和测试环境？
使用路径方式在本地扩展包
本地加载扩展包可以参考《Composer 扩展开发：本地运行扩展包》。
测试环境加载扩展包
在熟悉本地加载模式以后，其实测试环境也是一样，只不过需要运用 CI/CD 及时部署扩展包 develop 分支到测试环境的指定目录中。
根据环境安装不同来源的扩展包
通过上面的方法我们可以实现在本地加载本地指定目录下的一个扩展包，但是同时产生了一个新的问题——无法按照环境来安装对应的依赖。
比如，当我们本地开发好了以后，需要发版了，这时候你还得还原 composer.json 中的 repositories 得配置，以及 composer.lock 中的内容。这对于开发来说增加了很多心智负担。
我们的解决方案是，在项目目录下创建两套 composer.json 和 composer.lock 文件，一个用于生产，一个用于本地和测试。
composer.dev.json # 开发和测试环境
composer.dev.lock # 开发和测试环境
composer.json # 生产环境
composer.lock # 生产环境这时候如果我们本地要安装扩展包，只需要使用如下命令：
COMPOSER=composer.dev.json composer install当我们的扩展包开发完成，并且发布了新版后，我们需要更新本地的 composer.lock 文件，只需要执行如下命令：
composer update --no-install这么做的好处是即更新了线上的扩展包依赖，又不会覆盖本地的开发环境，如果不加 –no-install 参数的话，会导致 composer 从 Gitlab Composer Package Registry 拉取扩展包并覆盖掉本地的扩展包软连！
对于我们来说，只需要维护 composer.dev.json 和 composer.lock 中其他部分的一致性即可，repositories 的配置随环境的不同而不同。
改造后让我们团队节约出了大量时间和精力，专注于解决其他业务问题。
大家是如何实现私有扩展包的加载呢？欢迎讨论交换思路！
本作品采用《CC 协议》，转载必须注明作者和本文链接
，在国外吗
关于 LearnKu
粤公网安备 44030502004330号
推荐文章：