CNCF TAG App Delivery 怎样理解供应链交付边界

CNCF TAG App Delivery 不是某一个 CI/CD 产品，也不是把所有平台运维工作都收进来的总称。更准确的理解是：它围绕云原生应用从构建、打包、分发、部署到管理和运行的交付生命周期，整理共同模式、工作流和项目协作边界。

官方地址：https://tag-app-delivery.cncf.io/

判断“供应链交付边界”时，可以先问三个问题：交付的对象是应用制品还是平台能力？问题发生在制品流转还是运行时控制？团队需要的是交付流程建议，还是安全证明与策略约束？前两个问题通常落在 App Delivery 的主线，第三个问题往往需要和 Security 相关工作协同。

先把 App Delivery 放回一条完整链路

TAG App Delivery 官方主页把关注点概括为构建、打包、部署、管理和运行云原生应用，并说明其工作是收集开发者、平台工程师和最终用户的反馈，向相关项目反馈，再为使用者提供指导和示例。把这些词串起来，可以得到一条比“发布流水线”更完整的链路：

这条链路的价值在于，它把“供应链”从单纯的依赖扫描扩大为可追踪的交付过程，但并不意味着所有上游研发活动和所有下游基础设施运维都属于 TAG 的同一层。

为什么应用制品和基础设施不能完全分开

Platforms 工作组章程指出，很多交付场景只处理应用的打包格式和交付机制，却没有同时处理数据存储、消息队列、入口路由等基础设施依赖。结果是：应用包看起来完整，目标环境却缺少它真正需要的资源；或者应用和基础设施有各自独立的审批和生命周期，最后在部署阶段才暴露不一致。

因此，App Delivery 的边界不是“只管镜像”。当应用定义、参数、配置、打包和部署策略必须描述依赖关系时，平台协同就成为交付问题的一部分。但这仍然不等于 TAG 亲自管理每一种数据库、网络或云资源，而是要让交付工作流能够明确声明依赖、协调生命周期并反馈结果。

Artifacts 工作组解决的是“制品怎么走”

Artifacts 工作组章程将关注点落在云原生软件制品的打包、发现、分发和部署机制，并把应用打包与部署、包管理、交付工作流、配置源驱动工作流和发布管理列为与 TAG 章程相连的方向。这个范围很适合回答“一个应用交付包应该包含什么”和“它怎样从构建端可靠到达部署端”。

落到团队实践，可以把一个交付包拆成三类信息：

1. 应用内容：镜像、二进制、依赖包和应用配置的版本。
2. 环境契约：需要哪些数据、消息、网络、身份或存储能力，以及它们由谁提供。
3. 交付记录：从哪个来源构建、经过哪些发布阶段、当前被部署到哪里、状态如何返回。

如果团队只保存第一类信息，发布系统就很容易把“应用已经构建完成”误认为“应用已经可以运行”。如果只保存第三类记录，却没有对制品内容和环境契约做清晰描述，审计又会变成一串无法解释的流水线日志。

安全供应链是交付链路上的控制面

“供应链交付边界”最容易被误解的地方，是把 App Delivery 和软件供应链安全视为同一件事。二者确实共享构建、签名、仓库、部署和运行这些节点，但关注的问题不同：

• App Delivery 更关心应用如何被定义、打包、分发、部署和管理，以及不同项目如何互操作。
• 供应链安全更关心来源、参与者、构建过程、证明材料、策略和验证结果是否可信。
• 平台工程更关心这些交付能力怎样以可复用的门户、API、模板和运行服务提供给团队。

这不是三条互不相干的线。比如一个部署包需要附带来源和构建证明，发布平台需要在部署前执行策略，运行平台还需要把最终状态反馈给交付系统。更稳妥的做法是把安全要求作为交付对象的元数据和门禁，而不是把“安全”写成一个没有责任人的附加阶段。

如果文章或方案开始讨论签名、证明、策略评估、恶意篡改和验证者分发，应继续阅读 CNCF 安全相关资料，而不要仅凭 TAG App Delivery 的项目清单推导出完整安全结论。

相关官方资料：https://tag-app-delivery.cncf.io/wgs/artifacts/charter/charter.md、https://tag-app-delivery.cncf.io/wgs/platforms/charter/、https://tag-security.cncf.io/community/working-groups/supply-chain-security/

用四步判断一个问题该归到哪里

面对一个新工具、新规范或一条发布需求，可以按下面的顺序做归类。

1. 先写清交付对象。如果对象是镜像、包、清单、部署声明或应用运行状态，它通常在 App Delivery 主线上；如果对象是节点、集群、数据库服务本身，则要先看平台或基础设施边界。
2. 再定位生命周期动作。构建、打包、发现、分发、部署、升级、回滚和状态反馈属于交付流程的关键动作；密钥发行、策略执法和漏洞处置通常还需要安全或平台团队共同负责。
3. 检查是否存在依赖耦合。应用依赖入口、数据、消息或身份服务时，把依赖声明和生命周期协调纳入交付设计；不要把依赖留成“目标环境应该已经准备好”的隐含前提。
4. 最后补齐证据。记录制品版本、来源、环境、审批、策略结果和运行状态，使发布结果可以被下一个团队理解，而不是只留下一个“流水线成功”的绿色标记。

这四步的结果不是给项目强行贴一个标签，而是找出需要协作的边界。例如“如何把带有来源证明的镜像部署到带策略门禁的平台”同时涉及制品交付、安全控制和平台能力，适合拆成多个责任清晰的工作项。

给团队的最小落地清单

完成这张清单后，团队不一定需要立即更换工具。更重要的是，先能说清“什么被交付、谁负责提供依赖、哪些证据必须随制品走、出现异常由谁把状态带回来”。这正是理解 TAG App Delivery 边界后最有价值的工程结果。

常见疑问

App Delivery 是否等于 CI/CD？

不是。CI/CD 是常见实现方式之一，而 App Delivery 还包含制品描述、分发、部署、配置源驱动、升级、运行状态和相关项目协作。

只做镜像签名就完成了供应链交付吗？

没有。签名解决的是一部分来源和完整性问题，仍需要明确制品如何分发、部署到什么环境、依赖是否满足，以及运行状态如何反馈。

为什么应用交付要关心数据库和消息队列？

因为应用的可运行性往往依赖这些能力。把依赖声明和生命周期协调纳入交付流程，可以减少“应用包成功、环境却不可用”的断裂。

应该先研究哪个 CNCF 页面？

先从 TAG App Delivery 主页建立范围，再根据问题查看 Artifacts、Platforms 或 Security 相关资料。问题属于哪一层，比工具名称更适合作为入口。

总结来说，CNCF TAG App Delivery 的核心不是替团队规定唯一工具，而是把云原生应用从构建到运行的交付链路讲清楚，并让制品、平台能力和安全证据在边界处可以协作。把这三层分开再连接，才能避免把供应链安全缩成扫描按钮，也避免把平台运维误写成应用制品的一部分。