每天迭代 2 次也不慌：我们用 Pgyer 解锁内测效率新姿势-优快云博客

几乎每个移动端团队都经历过那种夜里赶版本的崩溃场面：
一个人打包，一个人传网盘，测试问“哪个是最新版？”，开发答“我发的那个”，然后发现发错了。

我们团队以前也一样。直到有一次严重的测试事故，才彻底决定：发包这件事必须自动化。

那次被“旧包”坑到的深夜

那是我们做的一个企业内部管理 App，版本更新很频繁。某个周四凌晨，测试组反馈一个关键 bug 没修复。
我回头一看日志，修复代码早就合进去了。结果发现他们装的是两天前的测试包。

那一刻我们彻底无语。
因为测试链接都存在 Slack 历史记录里，十几个人谁也说不清哪个才是最新版。
那天之后，我们开始认真调研内测分发方案。

我们选择蒲公英的契机

最初是一个同事提的：“要不直接试试 pgyer.com？我之前 side project 用过。”
我们抱着试一试的心态，接入了它的上传接口。没想到第一次构建就惊艳了。

我们在 Jenkins 里加了这一段：

curl -F "file=@app/build/outputs/apk/release/app-release.apk" \
     -F "_api_key=${PGYER_API_KEY}" \
     -F "buildUpdateDescription=Auto upload from Jenkins #${BUILD_NUMBER}" \
     https://www.pgyer.com/apiv2/app/upload

构建完成后，Slack 上自动出现一条消息：
“新版本构建成功下载链接：
https://www.pgyer.com/xxxx”

没人再去找包。没人再问“哪个版本”。
这是我们第一次感觉，自动化的内测分发，原来可以这么顺。

真正的价值在第二周体现

刚开始我们只是方便测试拿包，但很快发现更多潜力。
比如产品经理也可以扫码装包，不需要麻烦开发再发一遍。
又比如外包测试组用的 iOS 包，可以单独设置下载权限。

最妙的是，我们能在后台看到每次版本的安装统计。
这让我们第一次有了一个清晰的版本分布图——
哪些测试机覆盖了，哪些遗漏了，一目了然。

场景	之前的做法	现在的做法
临时修复 bug	手动打包 → 邮件发送	自动构建后直接推送到 Slack
跨团队共享测试包	上传网盘发链接	分配蒲公英下载二维码
验证安装覆盖	口头确认	后台自动统计设备数据

那种“测试走在构建之后两天”的节奏，被彻底打破。

不是“技术炫技”，而是减少浪费

在蒲公英的 API 接入之后，我们加上了一点自己的小优化逻辑：

版本号自动标记：上传时在 buildUpdateDescription 中自动附带 commit hash；
自动清理旧包：每周定时触发脚本，仅保留最近 10 次构建；
多渠道上传：按环境（dev / staging / prod）自动分组；

没有复杂的插件，没有新的依赖，一切都在 Jenkins 流程里安静地运行。
那种“版本总是最新”的确定感，成了我们工作流中最舒服的一部分。

一个好工具带来的连锁反应

两个月后，项目节奏明显快了。测试更快反馈，开发更快修复。
以前我们常说“提测”是一个事件，现在它只是流水线的一个阶段。

有次团队周会，产品经理笑着说：

“现在连装包都不用问人了，我都快以为自己成开发了。”

那一刻我们都笑了。
其实自动化并不是让工作变少，而是让大家能把精力花在更值的地方。

最后的感受

回头看，接入蒲公英这件事，没有多复杂的技术创新。
但它确实帮我们解决了一个最典型、最低效、又最容易被忽视的问题。

如果你也还在用网盘、钉钉群发包，那我真心建议试一次 pgyer.com。
不是因为它“炫酷”，而是因为它真的节省了时间。