在移动端开发里,构建与测试之间的交付往往是流程中最容易被忽视的一环。
很多团队在打包和测试之间,依然靠手动传文件、发链接来完成分发。
这种方式短期可行,但在多人协作和频繁迭代的项目中,会逐渐显现出问题。
本文不谈广告,只从一个开发者的角度,记录一下我在使用 蒲公英 (pgyer.com) 做分发的经验和一些技术思考。
一、分发的痛点:不是上传慢,而是信息混乱
在小团队中,最常见的分发模式大概如下:
- 打包生成 .apk 或 .ipa;
- 上传网盘或 IM 群;
- 通知测试人员安装。

看似简单,但问题集中在以下几个方面:
- 版本不可追溯:不同成员上传的包混在一起;
- 文件缺乏标识:没有备注、没有说明;
- 测试反馈割裂:测试与开发在不同工具中沟通;
- 自动化断层:构建系统与分发系统脱节。
这些问题在单人项目中可以忍,但一旦规模扩大,分发会成为流程中最不稳定的环节。
二、蒲公英的定位:一个分发层,而非工具集
蒲公英提供的不是一个“打包工具”,而是一层应用分发与版本管理服务。
它的核心作用是:
- 把构建产物(安装包)托管到一个统一入口;
- 提供 结构化的版本记录与访问方式;
- 让测试与非技术成员 独立获取并验证版本;
- 通过 API 接入自动化构建体系。
换句话说,它是 CI/CD 流程里的一块中间件。
对开发者来说,它的价值在于“减少人为环节”,而非“增加功能数量”。
三、日常使用体验:从“上传”到“集成”
我在日常项目中主要通过两种方式使用蒲公英:
1. 手动上传阶段(快速验证)
当需要快速验证一个功能或热修复时,我直接通过网页端上传。
上传完成后,系统会自动生成下载页和二维码。
这一点在与非技术成员协作时非常高效,不需要额外讲解流程。
2. 集成到构建流程(自动分发)
项目稳定后,我会把分发集成进 CI/CD 管线。
蒲公英提供的 API 接口结构清晰,参数直观,最常用的上传接口如下:
curl -F "file=@app-release.apk" \
-F "_api_key=your_api_key" \
-F "buildUpdateDescription=UI优化+性能调整" \
https://www.pgyer.com/apiv2/app/upload
集成后的构建流程大致如下:
git push
↓
CI 构建完成
↓
自动上传至蒲公英
↓
返回下载链接(含二维码)
↓
测试自动接收通知
从代码提交到测试人员拿到安装包,整个过程不再需要人工介入。
四、从 API 角度看,设计的合理性
API 设计直接影响自动化集成的成本。
蒲公英的接口规范属于“实用型”,不复杂,但满足自动化需求。
|
字段 |
类型 |
说明 |
|
_api_key |
string |
用户 API 密钥 |
|
file |
file |
上传的安装包文件 |
|
buildUpdateDescription |
string |
版本更新说明 |
|
buildInstallType |
int |
安装方式(公开 / 密码) |
|
返回 |
JSON |
含版本号、链接、二维码等字段 |
返回数据中包含唯一的 buildKey,开发者可基于此生成自定义的下载页或对接团队文档系统。
这种 轻量但完整 的接口形式,符合 CI 集成的设计思路:
只做分发,不干扰业务逻辑。
五、版本与协作:从“文件”到“记录”的转变
以前版本分发只是“上传文件”,现在更像是在维护一份“可查询的记录”。
蒲公英后台自动保存每次上传的版本号、时间、备注、上传者。
这让版本管理不再依赖开发者个人记忆。
举个例子:
|
上传时间 |
版本号 |
上传者 |
备注 |
|
2025-11-09 |
v2.3.1 |
Ray |
调整登录逻辑 |
|
2025-11-07 |
v2.3.0 |
Lin |
新增多语言支持 |
|
2025-11-04 |
v2.2.9 |
Ray |
修复深色模式显示问题 |
这个表不是文档整理出来的,而是平台自动生成的。
对于项目回溯、Bug 定位都有直接价值。
六、使用感受与不足
我个人认为蒲公英的定位是清晰的:
它不是要做 CI/CD 替代品,而是填补“构建之后、交付之前”的空档。
优点:
- API 易于接入,文档清晰;
- 上传与分发体验简洁;
- 版本历史可追踪;
- 权限体系满足团队协作。
不足:
- 统计分析偏基础;
- 不支持自定义字段或 webhook 回调;
- 大规模团队协作下权限粒度仍较粗。
总体上,它是一个“用得住”的工具,而非“看起来炫”的平台。
七、结语:让交付成为流程的一部分
如果说持续集成解决了构建自动化的问题,
那么分发平台的意义在于——让交付也被纳入同一条流水线。
对开发者而言,最理想的状态不是“上传快”,
而是“构建完成后,版本自然被分发到正确的人手里”。
蒲公英正好把这一点做得足够轻量,也足够稳。

被折叠的 条评论
为什么被折叠?



