Jenkins 自动化出包部署

一条 Jenkins 流水线覆盖 Unity/iOS/Android 三端出包：git push 触发，Unity batchmode 命令行构建，产物归档后飞书通知到人。

覆盖平台Unity / iOS / Android

触发方式Git Webhook

结果通知飞书 + 下载链接

背景

从盛和时期就开始用 Jenkins 做自动化出包。到了小鹏一张图，出包流程明显更复杂：多分支并行（开发、release、hotfix）、多版本共存、多平台产物（Unity 资源包、Android APK、iOS Archive）。出包不再是"某个同学本地打一下"能扛住的事。

问题

问题	表现	影响
手工出包	本地打开 Unity 点 Build，等几十分钟	占用开发机，人得盯着
环境不一致	"我本地能打出来，你打不出来"	产物质量取决于谁打的包
状态靠人肉查	同事轮流刷 Jenkins 页面看构建好没好	失败后知后觉
日志随手丢	打包失败只剩一句"打不出来"	排查没有第一手资料

方案

把整条出包链路固化成 Jenkins 流水线，任何一次构建都在同一台构建机、同一份脚本、同一个环境下跑：

flowchart TD
    A["Git Push"] --> B["Jenkins Webhook"]
    B --> C["Checkout 指定分支"]
    C --> D["Unity batchmode 构建<br>-batchmode -quit"]
    D --> E["Android Gradle /<br>Xcode Archive"]
    E --> F["上传 Maven / 分发平台"]
    F --> G["飞书通知<br>成功/失败 + 下载链接"]
    D -.失败.-> H["归档 build.log<br>供排查"]

关键取舍是 Unity 必须用 batchmode 命令行构建，而不是在构建机上开编辑器 GUI 点 Build。batchmode 不受编辑器 UI 状态影响（弹窗、焦点、崩溃恢复对话框都不会卡住流水线），日志全部进文件，这是无人值守构建的前提。

关键实现

Unity 命令行构建

/Applications/Unity/Unity.app/Contents/MacOS/Unity \
  -batchmode -quit \
  -projectPath /path/to/project \
  -buildTarget Android \
  -executeMethod BuildPipeline.PerformBuild \
  -logFile build.log

-batchmode -quit 表示无界面执行、完成后退出；-executeMethod 指定入口方法，构建参数（版本号、渠道、分支）通过命令行环境变量传进 PerformBuild；-logFile 把 Unity 的全部输出落盘——这份日志是排查"为什么打包失败"的第一手资料。

Jenkinsfile

pipeline {
    agent any
    stages {
        stage('Unity Build') {
            steps {
                sh 'unity -batchmode -quit -buildTarget Android ...'
            }
        }
        stage('Archive') {
            steps {
                archiveArtifacts artifacts: 'build/*.apk'
            }
        }
        stage('Notify') {
            steps {
                sh 'feishu-notify "Build success: v${BUILD_NUMBER}"'
            }
        }
    }
    post {
        failure {
            sh 'feishu-notify "Build failed: v${BUILD_NUMBER}"'
        }
    }
}

三个刻意设计：

• 产物归档进 Jenkins：archiveArtifacts 让每个构建号的产物可追溯，回滚到任意历史版本不用重新打包。
• 通知进飞书而不是邮件：团队活在飞书里，成功/失败 + 下载链接直接推到群，没有任何人需要去 Jenkins 页面手动查构建状态。
• failure 也要通知：post { failure } 保证失败一定触达，沉默的失败比失败本身更伤效率。

指标

维度	手工出包	流水线出包
触发方式	人在本地点 Build	git push 即触发
构建环境	各人本机，不一致	固定构建机，统一环境
结果触达	口口相传	飞书通知到人，附下载链接
失败排查	无日志可追	build.log 全量归档

内部具体耗时数字未脱敏，公开页只保留方法论级结论。

复盘

1. batchmode 是 Unity CI 的生死线。任何依赖编辑器 GUI 的构建都没法无人值守，这一步没做，后面全是空中楼阁。
2. 日志必须归档，且归档要早于失败发生。等打包失败了再去找日志，日志早就没了；-logFile 落盘 + Jenkins 归档要在第一次跑流水线时就配好。
3. 通知的终点是"人"，不是"系统"。流水线真正的提效不在构建本身，而在于把"构建状态"推给需要它的人——没人查的仪表盘等于没有。
4. 遗留方向：构建机单点，多分支并发时排队；产物分发还依赖人工把链接转给测试。后续可以把分发平台的上传和测试群通知也并进流水线，让"push → 测试机收到包"中间零人工。