game-ci-cd-pipeline

游戏 CI/CD 流水线

当任务是选择下一个游戏流水线产物，而不是泛泛而谈 DevOps 时，使用此技能。

每次运行时，game-ci-cd-pipeline 应回答两个相关问题：

1. 这属于哪个信号层级／晋级通道？
   • branch-gate — 快速合并／提交验证
   • nightly-package-candidate — 较慢的定期或手动触发的 QA／评审候选构建
   • release-certification-candidate — 受保护、已签名、审批严格的发布或认证候选构建
2. 在该层级中，最小且切实可行的下一个产物是什么？
   • 流水线设置
   • 阶段拆分
   • 缓存策略
   • 预检就绪度
   • 产物／发布规范
   • CI 信号强化
   • 或转交日志排查

选择产物前，请先阅读以下内容：

• references/intake-packets-and-route-outs.md
• references/pipeline-patterns.md
• references/signal-tiers-and-promotion-lanes.md

何时使用此技能

• Unity 或 Unreal 团队需要从零开始设置 CI/CD，又不想过度设计。
• 流水线反复不稳定、缓慢或不透明，实际问题在于工作流结构，而非某一条孤立日志。
• 构建、烹制／打包、缓存、产物或发布交接步骤不断出问题，损害了团队对流水线的信任。
• 团队仍在手动发布演示版／评审版／正式版构建，需要首个可复现的流水线方案。
• 发行商协作方、承包商或技术负责人需要一份精简的游戏流水线审查简报。

何时不使用此技能

• 主要任务是找出某一份 Unity／Unreal 构建日志中的首个可操作故障 → game-build-log-triage。
• 主要任务是协调设计、QA、构建压力和发布时间 → bmad-gds。
• 主要任务是进行运行时性能分析或诊断帧耗时瓶颈 → game-performance-profiler。
• 主要任务是处理 Steam 页面／愿望单／上线商店运营 → steam-store-launch-ops。
• 主要任务是为普通 Web／后端代码库处理通用的非游戏 CI/CD → 改用代码库中更广泛的 DevOps 技能。

指令

第 1 步：先判定信号层级，再选择一种主要产物类型

将请求归一化为且仅为一个信号层级和一种主要产物。

game_pipeline_packet:
  signal_tier: branch-gate | nightly-package-candidate | release-certification-candidate | unknown
  packet_type: pipeline-setup | stage-split | cache-policy | preflight-readiness | artifact-release | ci-signal-hardening | route-to-log-triage
  engine: Unity | Unreal | mixed | unknown
  ci_surface: GitHub Actions | Unity Build Automation | Jenkins | TeamCity | other | unknown
  target_platforms: Windows | macOS | Linux | Android | iOS | console | mixed | unknown
  release_context: prototype | internal QA | demo | playtest | certification | launch | live patch | unknown
  evidence_level: strong | partial | thin

信号层级含义：

• branch-gate — 快速合并／提交验证，其中昂贵的打包应仅在特殊情况下进行
• nightly-package-candidate — 定期或手动触发的 QA／评审／演示候选构建，耗时高于普通分支 CI
• release-certification-candidate — 受保护、审批严格、已签名、面向商店或认证的候选工作

产物含义：

• pipeline-setup — 为仍有过多手动操作的团队制定首个可复现的流水线计划
• stage-split — 将还原／构建／测试／烹制／打包／发布拆分为独立阶段，以便清楚显示首个失败阶段
• cache-policy — 消除对 Library、Intermediate、Saved、DDC 或打包缓存的盲目猜测
• preflight-readiness — 在昂贵的打包开始前，检查并呈现 SDK／签名／工具链／平台前置条件
• artifact-release — 规范产物命名和保留策略，明确区分候选版本与正式版本，并改善 QA 交接
• ci-signal-hardening — 在不重写所有内容的前提下，提升反馈速度和可信度
• route-to-log-triage — 请求主要涉及一条失败的构建或日志，应转交给 game-build-log-triage

步骤 2：收集最低限度的可信证据

仅提取足以支撑决策的最小证据包：

• 引擎及版本（如已知）
• 当前 CI 覆盖范围或工作流文件
• 当前触发方式：PR/推送、定时/手动、受保护的发布通道，或未知
• 目标平台和发布背景
• 重复出现的故障模式：编译、打包、工具链、缓存、产物混淆、速度或可信度
• CI 完成后仍需手动执行的事项
• 如果候选版本晋级是痛点，说明当前产物命名/保留或审批规则
• 如果团队总是提到某个单独的红色构建，提供一个近期失败的作业/日志

如果证据不足，应降低置信度，并优先选择 route-to-log-triage 或范围较窄的证据包，而不是假装进行全面重设计。

步骤 3：明确选择信号层级

在提出证据包建议之前，先确定哪个通道负责解决痛点：

• branch-gate：当问题是 PR/合并验证缓慢、每个分支都要进行繁重打包，或缺少快速反馈时
• nightly-package-candidate：当 QA/评审/演示构建需要更繁重的打包、更广泛的目标覆盖，或需要在常规分支 CI 之外进行定时/手动晋级时
• release-certification-candidate：当工作涉及大量审批、签名、商店/认证约束，或需要比普通 CI 更严格的产物保留规则时
• unknown：仅当现有证据尚不足以区分通道时

如果用户混淆了多个通道，应选择当前最影响信任度的通道，并将其他通道列为后续分流方向。

步骤 4：判定主要阻碍因素

选择一个主要阻碍因素，次要阻碍因素最多选择一个。

主要阻碍因素

• reproducibility-drift
• stage-boundary-blur
• dependency-cache-policy
• artifact-release-hygiene
• platform-toolchain-readiness
• feedback-speed-confidence
• single-log-not-pipeline
• unknown-needs-more-evidence

常见对应关系：

• “在一台机器上可以运行，但在 CI 中不行” → reproducibility-drift
• “我们的工作流是一个巨型作业，无法判断哪里出了问题” → stage-boundary-blur
• “我们总是在删除缓存，直到它通过为止” → dependency-cache-policy
• “QA 永远不知道哪个构建才是正确的” → artifact-release-hygiene
• “Android/iOS/主机平台打包失败得太晚” → platform-toolchain-readiness
• “构建很慢，而且没人信任这些信号” → feedback-speed-confidence
• “这是一个失败的打包日志” → single-log-not-pipeline

步骤 5：检查边界

给出建议之前，先确认通道：

1. 这是结构性流水线问题，还是只有一条失败日志？
2. 所选信号层级是否符合实际的触发/审批/产物问题？
3. 下一步最合适的材料是否属于上述证据包类型之一？
4. 是否仍在处理游戏引擎流水线，而没有偏离到通用 Web 应用 DevOps？
5. 引擎特定细节是否有助于诊断，而不是让入口内容变得臃肿？

如果问题主要是“这是一条失败日志”，则转交给 game-build-log-triage，并附上简短的交接证据包。 如果问题主要是“这实际上是发布门禁策略”，则将策略决策转交给 testing-strategies，并让此技能继续专注于游戏引擎的实现形式。

步骤 6：整理证据包简介

按以下精确结构返回：

# Game CI/CD Brief

## Packet choice
- Signal tier: branch-gate | nightly-package-candidate | release-certification-candidate | unknown
- Packet type: ...
- Engine: ...
- CI surface: ...
- Release context: ...
- Confidence: high | medium | low

## Evidence used
- Workflow / system context: ...
- Repeated failure pattern: ...
- Manual steps still outside CI: ...
- Gaps / assumptions: ...

## Primary blocker
- Bucket: ...
- Why it matters now: ...
- Evidence: ...

## Secondary blocker
- Bucket: ...
- Why it matters now: ...

## Recommended pipeline shape
1. ...
2. ...
3. ...

## Engine and platform checks
- Unity / Unreal specifics: ...
- SDK / signing / toolchain: ...
- Cache or artifact policy: ...

## Recommended next artifact
- Choose one: pipeline setup plan | workflow stage split brief | cache-key policy | platform preflight checklist | artifact/release checklist | CI-signal hardening plan | log-triage handoff packet

## Route-outs
- Skill: ...
- Why: ...
- Packet to pass: ...

## What not to do yet
- 1-3 bullets that avoid brittle rewrites or cargo-cult caching

步骤 7：根据引擎和信号层级调整数据包

对于 Unity

• 留意引擎／编辑器版本固定
• 询问 Packages/manifest.json／锁定输入和平台模块是否稳定
• 将包还原、构建、测试和打包阶段分开
• 将 Library/ 和包缓存视为明确的策略，而不是例行清理
• 对于 branch-gate，优先考虑快速编译／测试／冒烟反馈，以及进行中任务的取消行为
• 对于 nightly-package-candidate 或 release-certification-candidate，明确候选版本命名、构建目标分组、签名和制品保留规则

对于 Unreal

• 在概念上将 UBT/UHT、烹制、打包和发布分开
• 指出插件／模块偏差、资源重定向带来的问题，以及 AutomationTool 的可见性
• 区分 DDC／缓存问题与打包／日志根因分析工作
• 在后期失败发生之前，明确显示平台打包前置条件
• 对于 branch-gate，除非项目风险确实有此要求，否则避免让每次合并都必须经过完整烹制／打包
• 对于 nightly-package-candidate 或 release-certification-candidate，明确烹制／打包耗时、特定目标的前置条件，以及发布／晋级规则

步骤 8：索取最少的缺失信息

如果信心不足，只索取会影响决策的信息：

1. 当前工作流文件或作业大纲
2. 触发方式（PR／推送、定时／手动，还是受保护的发布通道）
3. 引擎版本和目标平台
4. 如果问题可能是 single-log-not-pipeline，提供一份近期失败的作业／日志
5. 当前制品命名／保留／审批模式
6. CI 完成后仍需手动执行哪些操作

输出格式

始终返回一份简短的游戏流水线简报。

必备要求：

• 选择一个信号层级和一种主要数据包类型
• 将结构性流水线工作与一次性日志排查分开
• 推荐一个下一步制品，而不是全面重写平台
• 控制在约 300–550 词，除非用户要求更多
• 如果发布／演示背景会改变优先级，务必明确说明
• 如果候选晋级／审批的实际情况会影响答案，务必明确说明

示例

示例 1：Unity 缓存迷信

输入

我们的 Unity GitHub Actions 构建在本地可以通过，但更新包后就会失败。我们一直删除缓存并重试，直到成功。

良好输出方向

• 数据包类型：cache-policy
• 主要阻碍：dependency-cache-policy
• 次要阻碍：reproducibility-drift
• 下一步制品：cache-key policy
• 仍可选择转交排查，但除非某条具体日志成为真正的问题，否则无需转交

示例 2：每个分支都进行繁重打包

输入

我们的 PR 流水线要跑 70 分钟，因为每个分支都会执行 Android 打包。应该先改什么？

良好输出方向

• 信号层级：branch-gate
• 数据包类型：ci-signal-hardening 或 stage-split
• 主要阻碍：feedback-speed-confidence
• 下一步制品：CI-signal hardening plan 或 workflow stage split brief
• 指出完整打包可能更适合放在更重的候选通道，而不是每个合并门禁中

示例 3：Unreal 巨型作业日志

输入

我们有一条 Unreal 流水线，但打包要花很久，而且失败信息都堆在一大坨日志里。

良好输出方向

• 信号层级：通常为 nightly-package-candidate，除非用户证明每次合并都确实需要完整打包
• 数据包类型：stage-split
• 主要阻碍：stage-boundary-blur
• 次要阻碍：feedback-speed-confidence
• 下一步制品：workflow stage split brief

示例 4：一份失败的打包日志

输入

我们的 Unreal Android 打包作业昨晚失败了。这是 AutomationTool 输出。

良好输出方向

• 数据包类型：route-to-log-triage
• 主要阻碍：single-log-not-pipeline
• 转交给 game-build-log-triage
• 附上失败阶段、引擎版本、目标平台和准确的日志摘录

示例 5：手动夜间版／演示版候选流程

输入

我们已经有快速分支构建，但 QA 需要一个夜间 Windows + Steam Deck 候选版本，并且构件名称要清晰明确。

良好的输出方向

• 信号层级：nightly-package-candidate
• 数据包类型：artifact-release 或 pipeline-setup
• 主要阻碍：artifact-release-hygiene
• 下一项构件：artifact/release checklist 或 pipeline setup plan
• 明确说明候选版本命名、保留策略和交接给使用方的流程

最佳实践

1. 先确定信号层级，再确定数据包——分支门禁、夜间版／软件包候选版本和发布／认证工作不应共用一个虚构的默认答案。
2. 像发布工程师一样行事，而不是泛泛讲解基础设施——选择能减少重复痛点的下一项数据包。
3. 保留日志／流水线的界限——一次构建失败往往需要先进行 game-build-log-triage，而不是直接重构结构。
4. 将缓存视为策略——定义缓存的键、共享方式、失效方式，以及需要有意重新生成的内容。
5. 明确各阶段的界限——编译、测试、烘焙／打包和发布不应合并成一团难以阅读的内容。
6. 明确呈现发布背景——原型、演示、认证和上线所需的权衡各不相同。
7. 优先选择一项下一步构件，而不是写一篇冗长的 CI/CD 宣言。
8. 如果争议焦点是治理而非引擎流水线结构，就将发布门禁策略交由 testing-strategies 处理。

参考资料

• references/intake-packets-and-route-outs.md
• references/pipeline-patterns.md
• references/signal-tiers-and-promotion-lanes.md
• Unity 文档 — 常见问题排查 • 构建自动化 • Unity 文档
• Unity Scriptable Build Pipeline — 缓存服务器客户端
• Epic 文档 — 打包项目
• Epic 文档 — Unreal Engine 中的日志记录