Tekton Pipelines Roadmap 全解析：规划看板、状态流转与贡献协作机制-平芜编程栈

云原生
CI/CD
DevOps
后端

【免费下载链接】pipeline

A cloud-native Pipeline resource.

项目地址：https://gitcode.com/gh_mirrors/pipelin/pipeline

Tekton Pipelines 的路线图（Roadmap）通过 GitHub Project 看板统一管理，把功能请求、TEP（Tekton Enhancement Proposals）、Epic 及其子议题、基础设施改进全部纳入一个透明、可追踪的规划体系。本文将基于仓库根目录的 roadmap.md 展开，完整讲解看板的状态定义、条目如何自动/手动进入看板、状态如何随 GitHub 事件自动流转，以及贡献者与维护者应遵守的最佳实践，并结合本仓库的源码与文档（发布节奏、功能开关、API 兼容性策略等）说明 roadmap 机制在 Tekton Pipelines 项目中的实际落地方式。

Roadmap 的目的与定位

Tekton Pipelines Roadmap 项目看板（Project Board）专门追踪tektoncd/pipeline组件的开发路线图，为社区提供"计划中的工作、进行中的工作、已完成的工作"的全景可见性。看板覆盖四类条目：

Feature requests and enhancements：功能请求与增强
TEPs：Tekton 增强提案（Tekton Enhancement Proposals），即社区级的设计提案
Epics and their sub-issues：史诗级任务及其子议题
Infrastructure improvements：基础设施改进

从本仓库的目录结构可以看出这些条目的实际产物：TEP 驱动的设计落地为 config 下的各类 YAML 配置与 pkg/apis/pipeline 中的 API 类型定义，基础设施改进则体现在 cmd、config/controller.yaml 等部署文件中。长期目标可参考 README.md 对项目定位的描述——提供 Kubernetes 风格的资源来声明 CI/CD 流水线，并坚持 Cloud Native（运行于 Kubernetes）、Decoupled（流水线与集群解耦）、Typed（类型化资源）三大设计原则。

状态列（Status Columns）定义

看板采用五个状态列，含义如下：

Status	Meaning
Todo	计划中的工作，尚未开始
In Progress	正在积极开发中
Review	实现已完成，等待评审
Done	已完成并关闭
Hold	暂停或被阻塞

这套状态语义与仓库中"功能毕业（Feature Graduation）"的稳定性阶段相辅相成：alpha → beta → stable 描述的是功能成熟度，而 Todo → In Progress → Review → Done 描述的是工作进度，两者维度不同。功能稳定性策略详见 api_compatibility_policy.md，进度状态则由看板自动化管理。

条目如何进入看板（How Items Get Added）

自动添加（推荐方式）

给tektoncd/pipeline仓库中任意处于打开状态的 Issue 或 PR 打上area/roadmap标签，自动化系统会：

将该条目添加到项目看板
将状态设置为Todo

此外，已在看板上的条目的子议题（sub-issues）也会被自动添加，这使得大型功能可以按 Epic → 子议题的方式拆解并全部纳入跟踪。

手动添加

对于没有area/roadmap标签的条目，维护者（Maintainers）可以通过项目看板界面手动添加。自动与手动两种方式互为补充，确保无论是标签驱动还是人工整理，路线图都能保持完整。

条目如何流转（How Items Move）

大多数状态转换由 GitHub 事件自动触发，同时保留少量手动操作入口。下图完整复现 roadmap.md 中的流转逻辑：

┌─────────────────────────────────────────────────────────────────┐ │ ENTRY POINTS │ ├─────────────────────────────────────────────────────────────────┤ │ Label "area/roadmap" added ───────────────► Todo │ │ Sub-issue created ───────────────► Todo │ │ Manually added to project ───────────────► Todo │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ AUTOMATED TRANSITIONS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Todo │ │ │ │ │ │ PR linked to issue │ │ │ Changes requested on PR │ │ ▼ │ │ In Progress │ │ │ │ │ │ Issue closed │ │ │ PR merged │ │ ▼ │ │ Done │ │ │ │ │ │ Issue reopened ──────────────────────► In Progress │ │ │ │ │ │ Closed > 1 year with no updates │ │ ▼ │ │ [Archived] │ │ │ ├─────────────────────────────────────────────────────────────────┤ │ MANUAL TRANSITIONS │ ├─────────────────────────────────────────────────────────────────┤ │ Any status ◄──────────────────────────────► Hold │ │ In Progress ──────────────────────────────► Review │ └─────────────────────────────────────────────────────────────────┘

流转规则要点：

Todo → In Progress：PR 关联到某个 Issue，或 PR 被要求修改（Changes requested）时自动发生——前者表示"有人开始干了"，后者表示"工作还在进行中，需要返工"。
In Progress → Done：Issue 关闭或 PR 合并后自动完成。
Done → In Progress：Issue 被重新打开时回退。
Done → [Archived]：关闭超过 1 年且无更新的条目自动归档。
手动转换：任何状态都可以手动切到Hold（暂停或阻塞），实现完成后由维护者手动从 In Progress 移到Review等待评审。

这套"事件驱动 + 人工兜底"的双轨设计，保证了看板状态与 GitHub 上的真实开发活动保持同步，避免出现"代码已合并但看板还停在 Todo"的漂移。

最佳实践（Best Practices）

贡献者（For Contributors）

Action	How
让你的功能进入路线图	给你的 Issue 添加`area/roadmap`标签
表明你在认领某项工作	将你的 PR 链接到对应 Issue——状态会自动变为 "In Progress"
拆解大型功能	使用 GitHub 子议题（sub-issues）——它们会被自动添加到看板
查看已规划的内容	提交新路线图条目前先查看 Todo 列，避免重复提议

维护者（For Maintainers）

Action	How
对路线图条目排定优先级	使用看板的拖拽功能在同一列内重排序
临时阻塞某项工作	手动将条目移到 Hold，并添加注释说明原因
标记需要评审	实现完成后手动将条目移到 Review
保持看板整洁	关闭超过 1 年的条目会自动归档，也可以手动归档
跟踪 Epic 进度	使用子议题——看板会展示子议题的完成进度

应避免的事项（Things to Avoid）

不要手动设置 Done——让自动化在 Issue 关闭或 PR 合并时处理
不要通过移除area/roadmap标签来从看板移除条目——标签移除后条目仍然存在；如需移除请归档
不要重复添加条目——添加新路线图条目前先搜索看板

这些"避免事项"本质上是保护自动化契约：手动改动状态或标签会破坏看板与 GitHub 事件之间的映射关系，导致后续流转失真。

Roadmap 机制在仓库中的落地佐证

roadmap 看板不是孤立的规划工具，它与本仓库的工程治理体系深度咬合，下面从源码与文档层面印证几个关键环节。

发布节奏：路线图产物的交付周期

规划中的功能最终通过月度发布交付。根据 releases.md，Tekton Pipelines 遵循语义化版本vX.Y.Z，每月产出一个新版本，其中每年 1 月、4 月、7 月、10 月选择四个版本作为长期支持版（LTS），其余版本约支持一个月。LTS 版本（如 v1.15.0、v1.12.0、v1.9.0）在路线图排期时通常需要更高优先级，因为它们承担更长的维护窗口。这解释了看板中为何需要 Hold、Review 等状态来精细管理不同版本窗口内的工作节奏。

TEP 与功能提案的入口

Roadmap 看板专门跟踪 TEP 条目。TEP 是 Tekton 社区级的设计提案，提案经评审后落地为代码。落地后的功能多数通过功能开关（feature gates）控制，其稳定性等级与 CRD API 版本相互独立，详见 api_compatibility_policy.md 的 Feature Gates 一节：alpha 功能默认关闭，需将enable-api-fields设为alpha才启用；v0.53.0 之后引入的新功能则改用每功能独立开关（per-feature flag）。

每功能开关的源码实现

从源码看，per-feature flag 的定义集中在 pkg/apis/config/feature_flags.go 中。其数据结构PerFeatureFlag位于该文件末尾（约第 480-491 行）：

type PerFeatureFlag struct { // Name of the feature flag Name string // Stability level of the feature, one of StableAPIFields, BetaAPIFields or AlphaAPIFields Stability string // Enabled is whether the feature is turned on Enabled bool // Deprecated indicates whether the feature is deprecated // +optional Deprecated bool }

Stability字段取值对应StableAPIFields（"stable"）、BetaAPIFields（"beta"）、AlphaAPIFields（"alpha"）三个常量（同文件约第 27-32 行）。各功能的默认开关也在此声明，例如 alpha 级别功能默认禁用（DefaultAlphaFeatureEnabled = false，第 34 行），而DefaultEnableAPIFields = BetaAPIFields（第 73 行）表明全局门控的默认档位是 beta。实际启停逻辑通过setPerFeatureFlag函数（约第 265 行）从 configMap 配置解析并写入特性开关。

从规划到落地：开发者如何新增一个带开关的功能

docs/developers/feature-versioning.md 给出了 roadmap 条目从提案走向实现的完整操作路径：

在 pkg/apis/config/feature_flags.go 中按PerFeatureFlag结构添加默认值（name + stability + enabled）；
编写单元测试，并更新所有需要 configMap 设置的测试用例；
集成测试先在 test/e2e-tests-kind-alpha.env 中启用新开关，晋升 beta 后迁移到 test/e2e-tests-kind-beta.env；
将开关键值加入 config/config-feature-flags.yaml 对应的管道配置 ConfigMap；
在 docs/additional-configs.md 的 alpha 功能清单中补充文档。

开发者还可以用 pkg/apis/config/featureflags_validation.go 提供的ValidateEnabledAPIFields辅助函数，在 webhook 校验阶段拒绝未开启对应开关的功能，保证"未上路线图、未开开关的功能不会误入生产集群"。

废弃机制：路线图的退出通道

与 Roadmap 的 Done/Archived 状态对应，功能的退出遵循 docs/deprecations.md 维护的废弃清单：例如 v1beta1 的 Task、TaskRun、Pipeline、PipelineRun 自 v0.50.0 起废弃，按照 beta CRD 兼容策略，最早可在 v0.62.0 移除。这意味着一个功能从进入路线图（Todo）到最终退役（Archived），全程都有文档化、可预期的生命周期管理。

总结：让路线图真正指导开发

Roadmap 看板的价值不在于多一张状态表，而在于它把"提想法 → 立提案 → 排期 → 开发 → 评审 → 发布 → 退役"的完整闭环自动化：area/roadmap标签负责收口新想法，GitHub 事件驱动状态流转省去人工维护成本，维护者仅需在 Hold、Review 等关键节点人工干预，而 Todo 列的定期查阅能有效避免重复造轮子。对于 Tekton Pipelines 的贡献者，遵守"打标签、链 PR、拆子议题、先查后加"四步最佳实践，就能让每个功能请求在路线图上留下清晰、可追踪的足迹；对于维护者，善用优先级排序、Hold 阻塞与自动归档，则能让路线图始终真实反映社区的投入方向。

延伸阅读：仓库根目录 README.md（项目概览与安装指引）、releases.md（版本节奏与 LTS 策略）、api_compatibility_policy.md（API 稳定性与功能开关策略）、CONTRIBUTING.md（贡献流程概览）。