解读

在国内 PHP 团队的日常迭代中，Composer 依赖更新往往由 Dependabot 自动发起 Pull Request。面试官问“自动 PR 合并策略”，并不是让你背 GitHub 文档，而是考察三件事：

1. 能否在保障线上稳定的前提下，把“人工点 Merge”变成“机器自动合”；
2. 是否理解国内代码托管（Gitee、Coding、阿里云 Code）与 GitHub 在权限模型、CI 资源、审批流程上的差异；
3. 能否用 PHP 生态工具（Composer、PHPUnit、Rector、PHPStan）把“自动合并”做得让测试、运维、安全三方都放心。
   一句话：给出一条“可落地、可回滚、可审计”的自动化闭环，而不是简单勾选 “Auto-merge”。

知识点

1. Dependabot 配置语法（package-ecosystem、schedule、ignore、groups）
2. GitHub/GitLab/Gitee 的 merge 权限模型与 CODEOWNERS 机制
3. CI 阶段的“质量门”：Composer audit、PHPUnit、PHPStan、Rector、Snyk、SonarQube
4. 国内镜像源（腾讯云、华为、阿里云 Composer 镜像）对版本号漂移的影响
5. 自动合并的三种触发方式：GitHub auto-merge、GitLab merge when pipeline succeeds、本地机器人（如 Mergify、Kodiak、企业微信机器人）
6. 回滚策略：Composer lock 回退、OPcache 平滑重启、灰度机器分组、快速熔断
7. 审计与合规：自动合并日志留存、钉钉/飞书群通知、变更单号与工单系统对接（如 Jira、禅道）

答案

我给团队设计过一套“三级门禁、灰度回滚”的 Dependabot 自动合并策略，已稳定运行 14 个月，核心步骤如下：

1. 配置精细化

   • composer.json 里用 ~ 和 ^ 锁主版本，避免大版本被动升级；
   • dependabot.yml 按功能分组（security、runtime、dev），security 走单独队列，最高优先级；
   • 国内源加 repositories.aliyun.com 镜像，防止 GitHub 抽风拉包失败。

2. CI 三级门禁
   ① 静态门禁：PHPStan level 8 + Rector diff，增量报错即失败；
   ② 单元门禁：PHPUnit 覆盖率下降超 2% 即失败；
   ③ 业务门禁：基于 Laravel 的 HTTP Test 回放核心下单链路，P99 延迟上涨超 10% 即失败。
   所有门禁通过后才可进入“可合并”状态。

3. 自动合并机器人
   因为公司代码在 Gitee 企业版，没有 GitHub auto-merge，所以自研 PHP 控制台命令 MergeBot，逻辑：

   • 监听 Gitee Webhook → PR 标签为 dependabot 且 CI 状态为 success；
   • 调用 Gitee API 检测至少 1 名代码所有者（CODEOWNERS）的 LGTM 评论；
   • 满足条件后，使用 Deploy-Key 把 PR rebase 到最新 master，再 fast-forward 合并，保证线性历史；
   • 合并后立刻打 deploy-ready 标签，触发 Jenkins 灰度发布到 10% 容器，5 分钟内无异常告警则全量。

4. 回滚与审计

   • 每次合并写入 MySQL 变更日志：包名、from→to 版本、合并人、合并时间、回滚命令；
   • 若灰度阶段 5xx 率>1%，Jenkins 自动执行 composer require 包:旧版本 --no-update && composer update lock，回滚时间<90 秒；
   • 飞书群机器人实时推送“合并+灰度”结果，方便值班工程师二次确认。

通过这套策略，我们把 87% 的补丁级依赖更新变成“0 人工干预”，全年因依赖升级导致的线上故障从 6 次降至 0 次，符合国内公司对“稳定第一、效率第二”的考核要求。

拓展思考

1. 如果公司切换到私有 Composer 仓库（Satis / Packagist Private），如何验证 Dependabot 仍能正确解析版本？
2. 当某个依赖的升级必须伴随 PHP 版本升级（如 PHPUnit 10 要求 PHP≥8.1），自动合并策略如何与“PHP 灰度扩缩容”联动？
3. 在“安全合规红线”下，金融类项目需要“双人审批”才能合并，如何在不破坏自动化的前提下，让第二位审批人只需点一次“确认”即可完成？
4. 国内多云架构下，CI 资源池可能分布在阿里云、华为云，如何确保 Dependabot 触发的流水线总能在 3 分钟内拿到空闲 Runner，避免排队导致合并窗口过期？