大一实习，我被一台 Mac 卡住了
先交代背景：今天要介绍的这个开源工具，是我大一暑期实习的产物------三个月，从第一行代码到三端全链路跑通，实习结束后我把它开源了出来。
故事要从一个所有 Unity 开发者都不陌生的痛点说起。版本提审前的深夜，你可能经历过这样的场景：切平台、改配置、点 Build，一遍又一遍地手动出包；签名证书、keystore 散落各处，换台机器就要从头配一遍；包打完了还得手动传 TestFlight、传 Google Play，盯着进度条等处理。这些事没有任何创造性，却吃掉大量时间和精力。
而我实习的团队，情况还要更极端一点------被一台 Mac 卡住了。
为什么做这个：一台 Mac，和一群等包的人
我实习的组是一个休闲游戏开发组，手上同时跑着好几个项目。每个版本节点，流程都一样：打 Google 的 AAB 和苹果的 IPA，传到 Google Play 测试轨道和 TestFlight，让美术和测试的小伙伴们装包体验、找问题。
安卓那边还算好应付：打出 APK 直接丢群里，完事。但 iOS 就犯难了。每一次出包都要走一遍这样的路：从 Unity 导出 Xcode 工程，传到 Mac，打开 Xcode 归档，再上传 TestFlight。更要命的是，我们组的主力开发机全是 Windows，Mac 只有一台。
这意味着什么？每个项目的 iOS 包，都要先在 Windows 上构建，把产物发到 Mac 上下载，再用 Xcode 打包上传。几个项目轮流来，那台 Mac 就在几个人的工位之间搬来搬去。等机器的人在等，等包的人也在等------整个团队测试流程的最大瓶颈，居然是一台电脑。
这样下去不行，我们决定自己写一款贴合实际工作流的全自动构建与上传工具------这就是 AutomationUnityBuild 的由来。
我们的解法：一台 Mac 部署，全员不再等包
思路很直接：把整套工具部署在那台唯一的 Mac 上，任何人通过网页或命令行提交任务，剩下的全部自动化。
现在，一键就能打出 IPA、AAB、APK，构建完成后通过 API 自动上传到 Google Play 测试轨道或 TestFlight；需要正式发版时，也能直接上传苹果商店和谷歌商店。那台 Mac 不再需要搬来搬去，也没有人再守在它旁边等包了。
我们是做海外方向的团队，后来 TikTok 小游戏的需求也进来了，于是顺手把 TikTok 平台的构建与上传也适配了进去------这也是它和不少同类工具最大的区别之一。
架构上我们做了明确的分层：
- CLI 是核心：所有构建与上传能力都在命令行层实现，稳定、可脚本化、可集成到任何已有流水线；
- Web 是多人协作层：网页端基于 CLI 能力扩展，解决的是"多个人同时要用"的问题------打包排队机制、账号体系、构建与操作审计日志，都在这层实现。
部署在公司内网，同事打开浏览器就能提交打包任务，不用排队抢机器，打包记录全程可查。团队测试流程里最慢的那一环，就这样被拉平了。
后来我们发现，这个痛点和解法，几乎每个多项目的中小游戏团队都会遇到。与其让它只在我们组内部用，不如把它开源出来------也欢迎大家来提建议、一起完善。
AutomationUnityBuild 是什么
一句话介绍：基于 .NET 8、开源自托管的 Unity 全平台自动化构建与发布工具链------从代码仓库到应用商店，全链路闭环。 最小形态是一个拷到 Mac 上就能用的命令行工具，团队形态下是网页打包平台。
它覆盖三个平台的构建能力：
- iOS：Git 同步 → Unity 导出 Xcode 工程 → xcodebuild 归档导出 → API 直传 App Store Connect / TestFlight；
- Android：APK / AAB 双格式构建签名 → Google Play Publishing API 直传，支持灰度比例配置；
- TikTok：WebGL 构建 → TikTok 开放平台 API 自动上传。
提供两种使用方式，按需选择：
- CLI 命令行：核心能力层，数字快捷指令、交互式配置向导、dry-run、环境检查，适合脚本党和已有流水线集成；
- BuildServer 网页端：登录、项目与配置管理、任务队列、实时日志、产物下载、权限与审计日志，非技术人员也能用。
核心能力一览
| 能力 | 说明 |
|---|---|
| 三端构建 | iOS / Android / TikTok，一套工具链统一管理 |
| 商店直传 | App Store Connect、TestFlight、Google Play、TikTok 开放平台自动上传 |
| 五类配置模板 | 项目 / 工程 / 版本 / 签名 / 证书模板一键填充，新成员上手不再依赖"只有某人会打包" |
| 网页可视化 | 打包任务、配置管理、存储管理，浏览器里全部搞定 |
| 邮件通知 | 构建成功/失败自动邮件提醒，支持 SMTP 465 隐式 SSL 与通知联系人列表 |
| 分层日志追溯 | 总日志、Unity、Xcode、Android 日志分层保存，配合配置快照，一次失败全程可查 |
| 安全边界 | Git 仓库白名单、路径根目录限制、敏感信息脱敏、登录审计、项目级权限隔离 |
| Docker 部署 | Docker-first 部署方式，服务器上几分钟拉起服务 |
全自动流水线：从开发到上架的闭环
传统流程是：开发提交代码 → 手动拉代码 → 手动打包 → 手动测试 → 手动上传商店 → 手动确认发布，每一步都要人盯着。
AutomationUnityBuild 把这条链路变成了：
scss
1┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
2│ 游戏开发 │ → │ 自动化构建 │ → │ 上传测试 │ → │ 上传商店 │ → │ 发布游戏 │
3│ (Unity) │ │ (CLI/Web) │ │ (TestFlight)│ │ (App Store) │ │ (灰度/正式) │
4└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
5 ↑ │
6 └──────────────────── 邮件通知 / 日志追溯 / 配置沉淀 ←─────────────────────────┘对照一下就明白差距：
| 环节 | 传统做法 | AutomationUnityBuild |
|---|---|---|
| 游戏开发 | 开发完手动打开 Unity，点 Build，等半小时 | Git 仓库配置化，一键拉取最新代码，Unity BatchMode 无人值守构建 |
| 自动化构建 | 记命令、翻路径、找证书、手工看日志 | CLI 快捷指令 / Web 点按钮，两种入口任选 |
| 上传测试 | 手动打开 Transporter 拖拽 .ipa，等上传，再进后台提交 | 构建完成自动调用 App Store Connect API，TestFlight 自动分发给测试组 |
| 上传商店 | 手工填版本号、选构建版本、提交审核 | 版本号自动 +1、Google Play 灰度比例可配、TikTok API 直传 |
| 发布游戏 | 群里发消息"包好了"，测试同学手动下载 | 邮件自动通知成功/失败、产物集中存储、历史构建可追溯、审计日志完整 |
打包不再是"某个人手上的活"，而是一条可重复、可追溯的流水线。
为什么不用现成方案？
你可能会问：Unity Cloud Build、fastlane、Jenkins 不香吗？都香，但各有各的门槛：
- Unity Cloud Build：付费服务，构建依赖云端，私有化定制和国内网络环境下的体验受限；
- fastlane：功能强大，但纯命令行工具链，没有可视化界面，各平台能力要自己拼装；
- Jenkins 等通用 CI：足够灵活，但从零搭一套"Unity 构建 + 签名 + 商店上传"的流水线，光胶水脚本就要写不少。
AutomationUnityBuild 的定位就是：针对 Unity 打包这个具体场景开箱即用，开源自托管不花钱，网页界面让团队里所有人都能用，而不是只有运维会用。
不止能用，还靠得住
工具类项目最怕"能跑但不敢用在生产"，所以工程质量和安全是我投入最多的地方：
- 质量：目前 156 次提交、323+ 个单元测试持续护航（覆盖 CLI 参数解析、配置模型、路径安全、Git 策略、Google Play API、BuildServer 路由等全部模块），版本已迭代到 v8.0，Apache-2.0 协议；
- 路径安全：Git 仓库白名单、路径根目录限制、符号链接越界防护，构建产物不会跑到不该去的地方；
- 服务安全：安全响应头、跨站写请求校验、项目级权限隔离、接口限流、敏感信息脱敏、登录审计；
- 任务可靠性：构建超时自动清理进程树、服务重启后任务状态恢复、配置文件原子写入，不怕半途出错。
写在最后
补充两个开头没展开的细节：实习期间我做了不止一个项目，这只是其中"为解决真实痛点而做"的那一个；大二开学我辞职返校，实习告一段落，但这个项目留了下来，替整个团队扛下了最磨人的发包环节。
问题足够普遍，方案足够完整，而被手动打包折磨的团队，一定不止我们一家。 所以开源仓库由我个人继续维护，社区才刚起步。如果你：
- 正在被手动打包折磨，想试试自动化；
- 用过之后发现 bug 或者有改进建议；
- 对 CI/CD、Unity 工程化感兴趣，想找一个能实际落地的项目参与贡献；
都欢迎来仓库看看。文档、Issue、功能建议、部署案例，任何形式的参与都是支持。
仓库地址：
- Gitee：gitee.com/chenfenglov...
- GitHub：github.com/chenfengyim...
觉得有用的话，点个 Star 就是对我最大的鼓励。