Unity 工程化与 DevOps

Unity 工程化的重点是让项目在不同机器、分支和平台上稳定导入、测试、构建和交付。Unity DevOps Principles 提供原则入口；具体落地需要锁定 Editor/包/插件版本，使用批处理模式和测试框架，并把构建产物与配置追踪起来。

原理：编辑器项目也需要显式输入

Unity 项目的关键输入包括 Editor 版本、Packages/manifest.json 与 lock 文件、脚本定义符号、目标平台、构建配置、资源导入设置和签名凭据。版本控制不只保存 Assets/，还要保存项目设置、包依赖和构建脚本；缓存必须能被删除后重建。

应用：最小 CI 管线

1. 验证：检查依赖锁文件、脚本编译、格式和资源引用。
2. 测试：在 EditMode 验证纯逻辑，在 PlayMode 验证运行时和场景集成。
3. 构建：用 -batchmode -nographics 等命令行参数调用固定版本 Editor，构建脚本显式选择平台和输出目录。
4. 验收：启动 Smoke、包体清单、加载/内存/帧时间预算和签名校验。
5. 制品：上传包、符号、日志、测试 XML、版本元数据和依赖清单。

Unity Test Framework 可作为测试发现入口；不要把“脚本编译成功”当作 PlayMode 或目标设备行为正确。平台特有功能应在真实设备或等价测试池中验证。

可重复构建清单

• Editor、模块、包和插件版本固定并可由 runner 取得。
• 构建脚本不依赖当前用户目录、编辑器窗口状态或本地缓存。
• Addressables/资源构建输出有版本标识，旧产物不会被误复用。
• 签名密钥从受控 Secret 注入，日志不泄漏敏感信息。
• 每个构建记录 commit、分支、版本、平台、构建机和依赖哈希。

取舍与常见坑

• 只在编辑器里点 Build：不可审计且难以复现；把参数和流程写进脚本。
• 缓存优先：Library 缓存能提速，但需要周期性 clean build 发现隐藏依赖。
• 过度并行平台矩阵：按玩家覆盖率和风险排序，保留高价值组合。
• 忽略资源导入差异：不同 OS、文件系统和纹理压缩模块可能产生不同结果。
• 把 DevOps 当工具采购：原则是反馈短、质量可见、交付可回滚；工具只是实现手段。