跨引擎 CI-CD 与自动构建

原理：构建是有输入的函数

可复现构建可抽象为：

流水线必须记录这些输入的版本或哈希；否则“同一个提交”也可能生成不同包。密钥、签名和商店凭据不进入源码，而通过受控环境注入。

典型流水线分层：

1. 变更层：提交、合并请求、标签和手动发布请求。
2. 验证层：格式检查、静态检查、快速单元测试、内容引用检查。
3. 构建层：无头导入/编译、打包、符号文件和版本元数据生成。
4. 验收层：启动 Smoke、关键流程、平台包校验、性能/体积阈值。
5. 交付层：制品库、测试渠道、正式渠道和回滚记录。

应用：统一流水线、引擎适配

flowchart TD
    C["提交或合并请求"] --> V["快速验证"]
    V --> B{"引擎适配器"}
    B --> U["Unity 无头构建"]
    B --> E["UE 自动化构建"]
    B --> G["Godot CLI 构建"]
    U --> A["统一制品验收"]
    E --> A
    G --> A
    A --> P["发布到测试渠道"]

引擎适配器只负责调用具体版本的 CLI、导入缓存和平台参数；质量门禁、制品命名、报告格式和保留策略保持一致。

建议最小实现：

• 固定 runner 镜像或工具链清单，锁定引擎版本和插件版本。
• 每个构建生成 commit + engine + platform + build number 元数据。
• 缓存只加速，不改变输入；缓存失效后仍能从干净环境构建。
• 将日志、测试结果、崩溃符号、包体清单和 SBOM 作为同一制品的附件。
• 将夜间全量构建与每次提交的快速门禁分开，避免开发反馈被慢任务阻塞。

质量门禁示例

UE 的 Automation Test Framework、Godot 的命令行模式和 Unity 的 Editor 命令行参数分别提供引擎侧入口；统一流水线不应假设它们的测试发现、退出码或资源导入行为完全相同，应在适配器中显式转换。

取舍与常见坑

• 缓存与可重复性冲突：缓存导入目录可能隐藏版本污染；定期执行干净构建。
• 只构建不验收：包成功生成不代表能启动、能联网或满足平台规则。
• 把 CI 当发布系统：CI 证明候选包质量，CD 还需要审批、分批、监控和回滚。
• 矩阵无限膨胀：优先覆盖玩家占比高且风险不同的平台，边缘组合用夜间或发布前验证。
• 秘密泄露：日志中遮蔽 token、证书路径和签名参数；构建产物访问采用最小权限。