CI/CD 流水线设计：从 lint、test、build 到发布、回滚、制品留存的最小闭环——发展脉络 × 2026 横向对比综合报告 未开始

题记与说明

课题：CI/CD 流水线设计：从 lint、test、build 到发布、回滚、制品留存的最小闭环
本文性质：两份章节报告的综合定稿——纵轴章（发展史，检索日 2026-11-01）与横轴章（2026-11-01 时间截面上的系统性横向对比，检索日同日）。综合时已完成三项工作：① 合并两章重复表述（六环节定义、GitHub/GitLab 制品留存参数、JetBrains 2026 调研数据、GitOps 回滚叙述，各只保留一处）；② 消除口径分歧（采用率数据保留横轴章"第三方转引、未直接抓取原报告"的口径警告）；③ 补上纵轴叙事缺位、由横轴章独有的事实（2025–2026 GitHub Actions 定价风波），使"免费经济学"线索在时间轴上闭合。来源链接方面，绝大多数原始来源链接已保留；少数初稿仅有检索摘要、无法给出可直接点开原始 URL 的条目（共 4 条，见参考来源逐条注明）。各条目的核验状态沿用原章节标注；本稿为按独立审读意见（8 条）逐条修订后的最终稿（修订要点见文末「修订说明」），修订中新增/更正的引用已于 2026-11-01 当日实际抓取或检索核实，其余原始页面未重新抓取。

TL;DR

CI/CD 最小闭环（lint→test→build→发布→回滚→留存）非一次设计，而是 2001–2024 年六波力量补齐：自动构建、交付与回滚理论、容器与流水线即代码、平台内置 CI/CD、SLSA/Sigstore 制品签名，直至 AI 代理进流水线"守门"。2026 年：前三环已同质化，选型差异集中在发布、回滚、留存；GitHub Actions（33%）是最短路径，GitLab（19%）六环节原生度最高，Jenkins（28%）存量第二但下滑。要点：发布制品长存、中间产物显式设短保留期（平台 90/30 天默认只作兜底，而非默认策略）；K8s 用 GitOps 使 git revert 即回滚；成本模型纳入自建 runner 计费与否；AI 代码走与人相同门禁。

纵轴：发展脉络

口径先行：什么叫"最小闭环"

本课题的"最小闭环"指一条软件交付流水线中不可或缺的六个环节：lint（静态检查）→ test（自动化测试）→ build（构建）→ release（发布）→ rollback（回滚）→ 制品留存。它的关键判据不是"哪家跑测试更快"，而是"这六个环节能否在同一个平台内以原生能力或一条可审计的链路闭合，而不需要拼接大量外部系统"。这条闭环不是某一天被某家公司一次性设计出来的，而是在二十五年里由六波不同性质的力量逐段补齐的：先是"自动构建"（CI 服务器），然后是"交付理论"（持续交付），接着是"流水线即代码"与容器化，再是"平台内置 CI/CD"，然后是"供应链与制品签名"，最后是 AI 代理进入流水线。下面按时间分六个阶段重走这条纵轴。

两点口径说明（"六波"与六个阶段的对应关系）：① 六波与六个阶段是近似对应而非严格的一一映射——"供应链与制品签名"一波横跨阶段四与阶段五，而 Nexus/Artifactory 开启的制品仓库潮内嵌于阶段二的叙述中、不单独占一波；② 部分标志性事件按主题而非年份区间归段（下列为代表性例子、并非封闭清单）——Fowler 2006-09 的《Continuous Integration》作为阶段一参与者的理论收束提前写入阶段一，2005 年 Hudson、2014 年首份 State of DevOps 报告与 2014-06-25 的《CanaryRelease》按主题归入阶段二，2018 年 Intuit 开源 Argo CD 与《Accelerate》出版按主题归入阶段三，2022-04 Vercel 收购 Turborepo 因承接阶段四"缓存经济学"线索而记在阶段四。

阶段一（1991–2005）：概念前史与第一台 CI 服务器

"持续集成"作为一种说法，最早可追溯到 Grady Booch 1991 年方法论著述中对 CI 一词的使用（此细节据 Wikipedia「Continuous integration」词条转述，未独立核验原书）。2001-03-30，CruiseControl 首次发布：这个 Java 框架由 ThoughtWorks 的 Matt Foemmel 创建，被广泛认为是第一款得到普遍使用的持续集成服务器（Wikipedia: CruiseControl；SourceForge 官方站点）。它把"定时从版本库拉代码 → 编译 → 跑测试 → 把结果反馈给团队"固化成一台服务器上的常驻进程，后来衍生出 .NET 版本 CruiseControl.NET 并带有几十个插件。lint 环节的前史则是 2002 年 Douglas Crockford 发布 JSLint——这是 lint 进入 JavaScript 世界并对后世工具谱系（JSHint → ESLint）产生决定性影响的起点（lint 谱系据 ESLint 官方关于页 与 Wikipedia 回溯）。

主要参与者：ThoughtWorks（CruiseControl、以及 CI 理论的布道者 Martin Fowler）、Crockford（lint）。驱动因素是 XP/敏捷运动强调"每天向主干提交、每次提交都要被构建验证"——Martin Fowler 2006 年 9 月发表的《Continuous Integration》给出了 CI 的经典定义与十项实践（单一源码库、自动化构建、自测试构建、快速反馈、每人每天提交主干、每次提交触发构建等），成为此后二十年的理论底稿（martinfowler.com，2024 年仍有更新；本文按主题将其作为阶段一的收束提前叙述，见上文口径说明）。

本阶段闭环完成度：只有 build+test 的"自动运行"，没有发布、没有回滚、没有制品留存——构建产物用完即弃。

阶段二（2006–2012）：CI 服务器大普及、CD 理论化、"回滚"被命名

• 2005 年，Kohsuke Kawaguchi 在 Sun 以业余项目写下 Hudson（按主题归入本阶段，见上文口径说明）。2010 年 Oracle 收购 Sun 后 Hudson 归属起争议：2011-01-11 Kawaguchi 发表博客《Hudson's future》，随后社区于 2011-02-01 正式分叉出 Jenkins（名字致敬漫画《The Far Side》里的管家角色）。Oracle 留下的 Hudson 逐渐消亡，Jenkins 凭海量插件成为此后十余年 CI 服务器的事实标准（jenkins.io 博客原文；Kawaguchi 在 artima 的记述）。
• 2010 年 7 月，Jez Humble 与 David Farley 出版《Continuous Delivery》（Addison-Wesley，Martin Fowler 主编 Signature 系列），系统提出"部署流水线（deployment pipeline）"：构建 → 自动测试 → 发布的每一次变更都要走一条可重复的流水线，让软件始终处于可发布状态（O'Reilly 书目页）。本课题标题里"流水线设计"一词，理论源头即在此书。
• "回滚"被命名：2010-03-01 Martin Fowler 发表 bliki《BlueGreenDeployment》（术语的推广归于 Dan North），2014-06-25 发表《CanaryRelease》。这两个条目把"发布不可回滚"这一古老痛点变成两种可复制的工程模式：蓝绿 = 两套环境瞬时切换、秒级回滚；金丝雀 = 小流量试错、控制爆炸半径（BlueGreenDeployment；CanaryRelease）。回滚从此从"救火动作"升级为"流水线的内建设计项"。
• 制品留存线：2007 年 Sonatype Nexus、2008 年 JFrog Artifactory 相继问世，"二进制仓库管理器"品类出现（年代据 JFrog 官方白皮书及两家公司公开资料回溯）。构建产物第一次有了持久化、可检索、可晋升（snapshot → release）的归属地，"制品留存"从可选变成流水线标配。
• 2011 年，托管 CI 诞生：Travis CI 被广泛视为首个面向 GitHub 的云端托管 CI 服务，push 和 pull request 自动触发构建、开源项目免费（Travis CI quickstart；rOpenSci 2020-11 回顾）；同年 9 月 Paul Biggar 与 Allen Rohner 创立 CircleCI（Y Combinator 系），以 Linux/付费 macOS 构建见长（Wikipedia: CircleCI）；GitLab 2011 年创建、2012 年推出独立的 GitLab CI 应用。
• 2014 年，Puppet Labs 发布第一份 State of DevOps Report（Gene Kim、Jez Humble 等参与），后由 DORA 延续为年度报告，确立部署频率、变更前置时间、变更失败率、平均恢复时间（MTTR）四大关键指标——流水线好坏第一次有了可量化的裁判尺（2014 报告 PDF；Puppet 对报告史的回顾）。（按主题归入本阶段，见上文口径说明。）

驱动因素：GitHub（2008 年上线）让"每次提交都在别人的服务器上构建一次"变成零运维成本的默认行为；SaaS 化把 CI 从"自建机房里的一台 Jenkins"变成"网页上一个绿色对勾"。本阶段闭环完成度：lint/test/build（自动触发 + 托管化）成熟，release/rollback 有了理论模式与制品归属地，但仍需大量人工接线。

阶段三（2013–2017）：容器化与"流水线即代码"

• 2013 年，Solomon Hykes 在 PyCon 上发布 Docker 0.1（脱胎于其 PaaS 公司 dotCloud 的内部工具）。容器把"构建产物"从"一堆文件"升级为"不可变、可签名、可处处复现的标准单元"，CI 构建出的镜像可以原封不动地进测试环境再原封不动地上线，"在我机器上能跑"一类事故被釜底抽薪（koder.ai 对 Docker 历史的梳理）。这也直接改变了 release 与 rollback 的物理实现：回滚 = 换回上一个镜像 tag。
• 2013 年 7 月，Nicholas Zakas 发布 ESLint（6 月开工、7-16 发文《Introducing ESLint》），动因是 JSHint 宣布弃用格式化配置。ESLint 把每条规则做成可插拔组件，奠定此后十年 lint 进入 CI 门槛线的基础（Zakas 原文；eslint.org/docs/latest/about）。lint 至此完成从"个人编辑器里的拼写检查"到"流水线第一个必过关卡"的身份转变。
• 2015 年 9 月，GitLab 8.0 把 CI 完全内置进主产品并对所有项目默认开启，不再需要单独的 CI 服务器（GitLab 官方博客）。"代码仓库即 CI 平台"的形态第一次大规模出现。
• 2016 年 4 月，Jenkins 2.0 正式发布，核心特性是原生 Pipeline as Code：原 Workflow 插件转正为 Pipeline 插件，流水线的 stage 定义从网页上的一堆勾选框，变成随源码一起提交、可评审、可回退的 Jenkinsfile（Jenkins 官方 2016 年度总结；Jenkins Wiki「Pipeline as Code」）。流水线本身从此成为受版本控制的制品——这是"最小闭环"在工程形态上的一次质变。
• 2017 年，Weaveworks 提出"GitOps"：以 Git 为唯一事实源、以声明式配置驱动 Kubernetes 的持续交付；2018 年 Intuit 开源 Argo CD（后成 CNCF 项目），把发布与回滚变成"对 Git 里声明的版本做 diff 与 sync"（GitOps 术语溯源；Argo CD 概览）。声明式发布让回滚具备机械可执行性：git revert 一次提交即完成一次发布回退。
• 2018 年《Accelerate》出版，将 DORA 四指标从行业报告提升为经研究检验的绩效科学（据 DORA 研究体系公开资料，未独立核验出版细节）。

驱动因素：微服务架构与 Kubernetes（2015 年开源）让环境一致性成为生死问题；流水线配置爆炸逼出了"配置即代码"。本阶段闭环完成度：六要素全部有了工程化形态，且 lint、build、release、rollback 均实现"声明式、可版本化"。

阶段四（2018–2021）：平台内置 CI/CD 与缓存经济学

• 2018 年 10 月 GitHub Universe 首次宣布 GitHub Actions；2019-08-08 GitHub 宣布 Actions 加入完整 CI/CD 能力（三平台构建、矩阵构建、托管 runner、市场），公共仓库免费；2019-11-13 在 GitHub Universe 正式 GA（Visual Studio Magazine 2019-08 报道）。CI 从"外挂系统"正式变成"代码托管平台的原生功能"，PR 页面里的绿勾从第三方跳转变成本平台内的一等公民。
• 制品留存进入平台规则：GitHub Actions 默认把构建日志与制品保留 90 天；2020-10-08 起，管理员可按仓库/组织自定义保留天数，工作流内也可用 retention-days 指定（公共仓库 1–90 天，私有仓库最长 400 天）（GitHub Docs: Removing workflow artifacts；2020-10-08 changelog）。"留多久"第一次以平台默认值 + 显式配置的方式进入流水线定义本身。
• 2020 年末 SolarWinds 供应链攻击（背景事件，据公开报道，未独立核验细节）与开源信任危机，直接催生 2021 年两件大事：Google 于 2021 年 6 月提出 SLSA（Supply-chain Levels for Software Artifacts）框架，为源码→构建→制品的完整性给出分级标准；同年在 CNCF 孵化 Sigstore，用短证书 + 透明日志为制品提供免管钥的签名与验证（SLSA 发布当日的 HN 讨论）。制品从"存下来就行"变成"存下来，还要能证明它是谁、在什么流水线里、用哪份源码造出来的"。
• 2021 年，Travis CI 收缩免费层，大批开源项目出逃（rOpenSci 早在 2020-11 就记录了这场迁移潮的酝酿）——托管 CI 的免费经济学第一次明显转向，最大受益者是刚满一岁的 GitHub Actions。
• 构建缓存的工业化：Jared Palmer 于 2021 年发布 Turborepo（Rust 编写的 monorepo 构建系统，以本地/远程缓存"记住你构建过的东西"为核心卖点），2022 年 4 月被 Vercel 收购（按主题归入本阶段"缓存经济学"线索的收束，见上文口径说明）后成为前端流水线缓存的事实标准之一，与 Nx 的远程缓存形成双雄（TechCrunch 收购报道；vercel/turborepo 仓库）。build 环节从"每次全量"进入"内容寻址 + 增量复用"时代。

驱动因素：开发者体验竞争（谁的流水线离代码最近）、CI 分钟数成本与速率限制的经济压力、供应链攻击的持续加码。

阶段五（2022–2024）：lint 提速革命与制品签名为王

• 2022 年，Charlie Marsh（Astral）发布 Ruff：Rust 编写、单二进制、内置数百条规则、比 flake8 + isort + pyupgrade 组合快 10–100 倍，可一次性替代 flake8、isort、black、pydocstyle、pyupgrade 等一串 Python 工具（Ruff 仓库；Astral 官方博客）。lint 从流水线里"最容易被嫌慢的环节"变成"秒级完成"，使"每个 PR 都跑全量 lint"在超大仓库里也成立；随后同类思路（Rust 重写检查器）扩散到 JS 生态（Biome 等，时间线未独立核验）。
• 2023 年 4 月，npm 包 provenance 公开上线：npm publish --provenance 依托 GitHub Actions/GitLab CI 等受支持 CI 的 OIDC 签发，满足 SLSA Build L2（据检索摘要，同年 9 月宣布 GA），npm 包获得防构建后篡改的 provenance 保护（GitHub 官方公告：Introducing npm package provenance，2023-04-19；npm 官方文档：生成 provenance 声明；GA 时间点出自 GitHub Changelog 的检索摘要，该 changelog 链接本次抓取未命中，故未列出）。初稿此条曾误标为"2023 年 5 月"并误引 2021 年的 SLSA 发布 HN 讨论作证，本次修订已更正（见修订说明第 1 条）。
• 2024-03-29，XZ Utils 后门（CVE-2024-3094）曝光：攻击者"Jia Tan"以约两年时间取得项目维护者信任，把恶意载荷藏在构建流程中（伪造的 build-to-host.m4），混入 5.6.0/5.6.1 版本；微软工程师 Andres Freund 因 SSH 登录延迟约 500ms 的异常发现端倪。事件虽在多数稳定发行版之前被拦下，却成为"构建过程本身不可信"的标志性案例（CERT-EU 公告 2024-032；事件复盘）。
• 2024-06-25，GitHub Artifact Attestations 正式 GA：在 GitHub Actions 内为构建产物生成由 Sigstore 无密钥签名的 SLSA provenance 证明，用 gh attestation verify 即可验证"这个二进制确实出自这个仓库的这条工作流"（GitHub 官方 GA 公告；官方文档：用制品证明建立 provenance）。制品留存的语义就此改写：留存对象从"二进制文件"扩展为"二进制 + 可验证的出身证明"——闭环中最年轻的一环完成其现代形态。

阶段六（2024–2026 至今）：AI 代理进入流水线，闭环回到"守门"本义

AI 编码代理开始成规模地直接向仓库提交 PR，流水线的角色随之向"机器产出的守门员"回归：业界共识是 AI 生成的代码必须走与人完全相同的分支保护、必需检查（required checks）与人工评审门，否则 lint/test 门槛形同虚设；StepSecurity 在 2025 年的分析中点名了"AI 编码代理跑在 GitHub Actions 里"带来的凭据泄露与提示注入等隐性风险（StepSecurity: When AI Meets CI/CD）。GitHub 推出 Agentic Workflows（gh-aw），允许 AI 代理读取 issue/PR 上下文、生成修复并自动开 PR，"从 issue 到生产"的最短路径被进一步压缩——流水线的输入第一次不再必然来自人类（DeployHQ 综述）。

回滚一环在声明式发布成熟后继续下沉：GitOps（Argo CD/Flux 系）下回滚即 git revert + 自动 sync，蓝绿/金丝雀承担"出事前的减损"，feature flag 承担"无需重新部署的功能级止损"，三者共同构成现代发布安全网（GitOps 与 Argo CD 溯源）。平台格局（2026-03，JetBrains 调研口径，经第三方转引）：GitHub Actions 以约 33% 的组织采用率居首，Jenkins 约 28%、GitLab CI 约 19%；前云时代的 Jenkins 仍靠存量与自托管场景据守第二（JetBrains TeamCity 博客 2026-03；2026 工具对比）。

纵轴收束：六个要素各自"何时长成"

三条贯穿性判断（供交叉分析使用）：

1. 闭环的每一段都是"事故先行"：回滚模式成型于发布事故的常态化，制品签名成型于 SolarWinds/XZ 式供应链攻击，AI 守门成型于 AI 生成代码的泛滥——最小闭环的进化史是一部"打补丁史"。
2. 配置的代码化程度单向递增：构建脚本（Ant）→ 流水线文件（Jenkinsfile 2016）→ 环境声明（GitOps 2017）→ 保留策略与签名配置（retention-days、attestation 2020–2024），流水线里曾经"只有管理员能在网页上改"的东西全部变成了可评审、可回退的代码。
3. 留存与验证是最后的短板，也是当下主战场：前二十年解决"能不能自动跑完"，2017–2021 解决"跑得快不快、离代码近不近"，2021 年至今解决"留下的制品能不能自证清白"，2024 年后解决"当写代码的不是人时，谁来作证"。

横轴：横向对比（2026-11-01 时间截面）

对比框架

对比对象按形态分四类：托管型 SaaS（GitHub Actions、CircleCI、Travis CI）；代码托管平台内置（GitLab CI/CD、Azure DevOps Pipelines）；自托管经典/开源（Jenkins、Woodpecker CI、Drone CI、TeamCity；其中 Buildkite 为该类目下的混合型——控制面 SaaS + 自备算力）；云原生/新范式（Argo CD——GitOps 拉取式 CD、Tekton / Argo Workflows、Dagger）。范围声明：其中 Drone CI、Tekton、Argo Workflows 三个对象因检索所得信息有限，仅作背景提及、不入总对比表（Drone 见维度四的成熟度讨论，Tekton 见维度四的成熟度讨论、Argo Workflows 见维度三的生态讨论）；下表覆盖其余十一个对象。对比维度五项：闭环能力覆盖、成本、生态、成熟度、适用场景。核心问题不是"哪家跑测试更快"，而是"哪家用最低的成本和最少的粘合代码，把六个环节闭合起来"。

总对比表

逐维度对比

维度一：六环节能力覆盖。 lint/test/build（环节 1-3）所有主流平台都支持，差异在编排语法与缓存机制：GitHub Actions 用 YAML workflow + actions/cache；GitLab 用 .gitlab-ci.yml + stages；CircleCI 的依赖缓存与资源分级（resource class）被 2026 年多篇对比文章认为是托管平台中原生支持最成熟的；Jenkins 依赖 Jenkinsfile（Groovy）+ 插件，灵活但易腐化。release（环节 4）：GitHub Actions 可通过 Environments（环境保护规则、人工审批）+ Releases 原生完成；GitLab 有内置 Container Registry、Package Registry 和 environments；Jenkins、Woodpecker 等需要接外部 registry 与部署脚本。rollback（环节 5）是差异最大的环节（判据：平台是否提供原生回滚动作与防误部署保护，而非"绕道能否实现"）：GitLab 提供环境页面的一键 Rollback 按钮——本质是重新运行指向旧 commit 的部署作业，并有 "Prevent outdated deployment jobs" 保护设置（GitLab docs: environments）；GitHub Actions 没有专门的回滚按钮，需区分两种做法：re-run 旧的 workflow run 严格说不是回滚而是"重放"——它重跑同一次 run（同一 commit；失败作业重跑沿用原 commit 的 workflow 文件版本，重跑次数受 run 保留期限制，GitHub Docs: Re-run workflows and jobs），适合"上一次部署 run 失败了重试一次"，不能把环境送回旧版本；re-deploy 旧 tag/commit 才语义上是回滚——对旧 tag 重新触发部署工作流（如 workflow_dispatch 或重跑该 commit 上一次成功的部署 run），把环境送回旧版本，但要重新走一遍环境审批门，且依赖旧 commit 的部署作业可复现、相关制品仍在保留期内（此为社区惯用约定，官方无一键功能，惯例的普遍程度未独立核验）；K8s 场景下 Argo CD 把回滚彻底改写——Git 仓库即期望状态，回滚等于 git revert，GitOps 工具自动对账收敛。制品留存（环节 6）：GitHub Actions 默认保留 90 天，retention-days（1-90）可按任务覆盖，私有仓库可放宽至最长 400 天（GitHub Docs；actions/upload-artifact）；且 GitHub Releases 的附件不计入 Packages/Actions 存储配额，每个 release 最多 1000 个文件、单文件 2 GiB、总量无上限（GitHub Docs: About releases；社区讨论 #210936）；GitLab 制品默认 30 天过期，expire_in 可按任务覆盖，最新 ref 的成功流水线制品会被保留（GitLab Docs: job_artifacts；管理设置）；Jenkins/Woodpecker 自托管留存完全自管——磁盘满了就是运维事故。小结：六环节原生覆盖度上 GitLab CI/CD 与 GitHub Actions 并列第一梯队——"并列第一"的判据是"六环节能否在平台内以原生或低胶水成本闭合"，而非"每环都有原生按钮"：GitLab 六环全原生、回滚有按钮；GitHub 六环亦均可原生达成，唯回滚缺专门按钮、需按约定复用部署机制；CircleCI/Azure DevOps 第二梯队；Jenkins/Woodpecker 需自建环节 5-6；Argo CD 只覆盖环节 4-5，但把这两环做到了最可靠。

维度二：成本。 2026 年 CI/CD 计费的最大事件是 GitHub Actions 定价风波：2025 年 12 月中旬 GitHub 宣布自 2026-03-01 起对自托管 runner 收取 $0.002/分钟的"云平台费"（此前自托管完全免费，社区估算单个 24×7 runner 约多花 $84/月，有公司估算月增 $3.5k），引发强烈反弹后 GitHub 官方宣布推迟该收费，同时 2026-01-01 起托管 runner 降价最多 39%（GitHub Changelog 2025-12-16；官方定价说明；HN 讨论）。截至 2026-11-01，GitHub 官方计费文档（横轴章当日直接抓取 docs.github.com 核实）仍列明：自托管 runner 不消耗包含额度、不收费；免费档每月含 $12 计算额度（按 Linux 2-core $0.006/分钟折算约 2000 分钟）、Pro/Team 含 $18（约 3000 分钟）、Enterprise Cloud 含 $300（约 50,000 分钟）；Windows $0.010/分钟、macOS $0.062/分钟；免费档存储 500 MB，超出 $0.25/GB·月。GitLab 侧（横轴章当日直接抓取 docs.gitlab.com 核实）：Free 档 400 计算分钟/月，Premium 10,000 分钟/月，Ultimate 50,000 分钟/月；成本因子按 runner 规格放大（Linux small=1、medium=2、large=3、GPU medium=7、macOS M1 medium=6）；自建 runner 不消耗计算分钟配额——这是 GitLab 与 GitHub 计费模型的关键差异，解释了重度 CI 团队"GitLab + 全自建 runner"的低成本路线。Premium $29/人/月（年付）来自搜索摘要引用的 GitLab 官方定价页（该页直接抓取超时，价格以官方页为准，about.gitlab.com/pricing）。CircleCI 免费档 30,000 credits/月（1 credit ≈ $0.0006；Linux Medium 资源 10 credits/分钟，约合 3,000 分钟），开源项目可达 400,000 credits/月（circleci.com/pricing 检索）。Buildkite 采用"控制面按席位 + 算力自带"模式（正文旧口径 $0/$9/$19/$35 每人每月四档；官网 2026-11-01 实测为 Free $0（≤5 用户）/ Pro $30 每活跃用户/月 / Enterprise 定制三档，以官网为准，见参考来源），算力成本自担但无分钟数焦虑。Jenkins/Woodpecker/TeamCity 本地版本身免费或低价，真实成本是运维人力。小结：小团队最小闭环的成本最优解通常是"公开仓库 GitHub Actions 免费"或"GitLab Free + 自建 runner"；规模化后自建 runner 的计费豁免（GitLab 明确豁免、GitHub 当前状态）是最大的成本杠杆。

维度三：生态。 GitHub Actions 拥有最大的 Marketplace，任何新工具（linters、SAST、云 SDK）默认先发 GitHub Action，这是环节 1-3"零拼装成本"的来源。GitLab 的生态胜在"内置"：registry、安全扫描、依赖管理在同一个平台，不需要跨系统粘合。CircleCI 有 Orbs 复用机制。Jenkins 插件超 1800 个但质量参差、升级互踩是最大痛点（semaphore.io；northflank.com）。Woodpecker 社区规模小但路线清晰（Apache 2.0，支持 GitHub/GitLab/Gitea/Forgejo/Bitbucket）。Argo CD 背靠 CNCF Graduated 项目群（Argo Workflows/Rollouts/Events），是 K8s 生态内 CD 侧事实标准。Dagger 代表"用通用编程语言写流水线"的新生态，2026 年已进入多篇 CI-as-code 安全与选型对比文章的主流名单。

维度四：成熟度与采用率。 JetBrains《State of Developer Ecosystem 2026》调研（经第三方文章转引，未直接抓取原报告）显示：GitHub Actions 组织采用率 33%、Jenkins 28%、GitLab CI/CD 19%，CircleCI/TeamCity/Buildkite 各占细分位置。初稿曾并列转引 2026 年对比文章的"GitHub Actions ~85% vs Jenkins 59%→54%"个人开发者口径数字，因未保留来源链接、口径定义不明（年份、样本与统计基数无法确定），本次修订予以删除，只保留定性判断——个人开发者口径的方向与组织口径一致：GitHub Actions 已居首，Jenkins 在缓慢衰退但存量巨大。Travis CI 已边缘化；Drone 被 Harness 收购后开源动能减弱，其社区血统由 Woodpecker CI 延续（2026-07 仍有两者专门对比文章；初稿仅检索摘要、未保留原始链接，见参考来源注明）。Argo CD 与 Tekton 在云原生侧已属成熟；Dagger 仍属早期快速成长。

维度五：适用场景（对本课题的映射）。 个人/小团队、代码在 GitHub：GitHub Actions 是最短路径——lint/test/build 免费、Releases 免费长存、Environments 提供审批门禁，回滚按 re-deploy 旧 tag 的约定即可接受（re-run 只是重放同一次 run，严格说不是回滚）。需要私有化、跨阶段审计一体化：GitLab 的环境回滚按钮 + 内置 registry + expire_in 留存策略是六环节原生度最高的选择，自建 runner 后成本可控。K8s 原生团队：CI 只负责到"构建并推送镜像"，发布与回滚交给 Argo CD——git revert 即回滚、Git 历史即审计日志，这是 2026 年最普遍的 CI/CD 分工范式。构建性能敏感/缓存密集：CircleCI 的资源分级与缓存成熟度优于默认配置的 GitHub Actions。遗留系统/强内网管控：Jenkins 仍难替代，但对维护成本要有清醒预期。算力主权诉求：Buildkite（控制面托管+算力自备）或 Woodpecker（纯自托管开源）。

横向四判断

1. 闭环的重心正在从 CI 向"发布+回滚"两环倾斜。 lint/test/build 在所有主流平台已同质化，真正的选型差异集中在环节 4-6：GitLab 的环境回滚、GitHub 的 Releases 免费留存、Argo CD 的 GitOps 回滚，构成三种典型的"闭环收口"方式。
2. 制品留存是免费的还是昂贵的，取决于你把"发布制品"和"流水线中间产物"放在哪里。 GitHub 上两者待遇天差地别（Releases 不计配额 vs Actions 制品 90 天+存储费）；GitLab 统一按 30 天过期但可覆盖。最小闭环应明确"最终制品进 Release/Registry 长存、中间产物短保留"的双层留存策略。
3. 2026 年的定价信号表明托管 CI 的"免费午餐"正在被重新定价。 GitHub 对自托管 runner 收费的尝试虽被推迟，但方向已亮明；GitLab 对自建 runner 的豁免、Buildkite 的 BYO-Compute 模式、Woodpecker 的纯开源路线，都是对"计算费=平台税"这一趋势的对冲。选型时应把"自建 runner 是否计费"作为长期成本模型的显式变量。
4. "最小闭环"本身可以分层实现。 最务实的推荐路径：GitHub Actions（CI 四环 + Releases 留存）起步 → 发布规模变大后加 Argo CD 接管发布与回滚 → 或迁移到 GitLab 获得全内置闭环。三条路线互通——准确地说，是流水线的逻辑结构可平移、语法需改写：阶段划分（lint→test→build→deploy）、作业与依赖关系、缓存与产物意识可原样带走；但配置语言并不通用（GitHub Actions 的 runs-on/steps 对 GitLab 的 stages/script，缓存从 actions/cache 改写为 GitLab 的 cache:paths/policy，触发器与保护规则各有一套），GitLab 官方即提供从 Jenkins/CircleCI 迁移的指南（GitLab Docs: Migrate to GitLab CI/CD，存在性经本次修订检索确认；直接抓取被站点防护重定向）。粗略迁移成本（经验粗估、非实测）：一个典型服务的 lint/test/build 段落改写约半天到一天，主要耗在触发器、缓存与制品配置的对齐；Jenkins Groovy 管道则需重写编排逻辑，按插件依赖程度数天不等。早期选择并不锁死后期架构，但"可移植"应理解为结构可移植，而非配置文件可直接复用。

交叉洞察：两轴合起来说明了什么

洞察一：纵轴的"事故先行"规律与横轴的"重心后移"是同一枚硬币的两面。 纵轴章证明六环节是按 lint/test/build → release/rollback → 留存验证的次序逐段成熟的，越晚成熟的环节越是被事故倒逼出来的（发布事故倒逼蓝绿/金丝雀，供应链攻击倒逼 SLSA/Sigstore/attestation）。横轴章则显示，2026 年各平台在最先成熟的前三环上已经打不出差距，真正拉开选型差距的恰恰是最晚成熟的环节 4-6——GitLab 的一键回滚、GitHub 的双层留存、Argo CD 的 git revert。两轴互为印证：一个环节在纵轴上成熟得越晚，它在横轴上就越是差异点、也越是选型时的考察重点。 对用户的推论是：选型演示别看"测试跑得多快"，要看"回滚怎么做、制品留多久、出身能不能验证"。

洞察二：配置代码化的终点是"策略代码化"，而留存策略是今天各家最大公约数的短板。 纵轴第三章判断"配置代码化单向递增"，2020-2024 年走到 retention-days 与 attestation 这一步；把它放到横轴上看，GitLab 用一行 expire_in、GitHub 用 retention-days + Releases 不计配额，而 Jenkins/Woodpecker 的留存仍是"磁盘满了就是运维事故"的脚本工程。也就是说，"策略即代码"的进度在不同平台上是不同步的，这正是横轴打分的依据所在。落地建议：无论选哪家，留存都应写成流水线定义的一部分——发布制品进 Release/Registry 长存、中间产物显式设短保留期（GitHub 90 天默认、GitLab 30 天默认只该是兜底而非默认策略），并用 attestation 把"可验证出身"纳入留存对象。

洞察三：免费经济学每隔几年重定价一次，横轴的静态比价必须配上纵轴的时间维度。 纵轴上这条线索清晰可见：2011 年托管 CI 以"开源免费"起家 → 2021 年 Travis CI 收缩免费层引发迁移潮、GitHub Actions 接盘 → 2025-12 GitHub 尝试对自托管 runner 收费（$0.002/分钟）被反弹推迟、同时托管 runner 降价最多 39% → GitLab 明确自建 runner 不消耗配额、Buildkite 把算力留在用户手里。把这条时间线叠到横轴的计费表上，结论就不是"今天谁便宜"，而是：平台随时可能改规则，唯一稳的杠杆是把计算负载握在自己手里（自建 runner）且选对明确豁免自建算力计费的平台。今天的"免费"是获客手段而非承诺，成本模型应按"自建 runner 是否计费"这个变量做敏感性测试，而不是按当月账单线性外推。

洞察四：AI 代理让纵轴回到起点，也让横轴的竞争焦点从"跑得快"转向"证得清"。 纵轴的起点是"机器定时替人跑构建"，2024 年后 AI 代理进一步替人写代码、开 PR（Agentic Workflows 甚至让流水线输入不再来自人类）——闭环的"守门"职能被空前放大，这解释了为什么 required checks、人工审批门、凭据隔离成为 2025-2026 年的讨论中心（StepSecurity 的风险分析）。放到横轴上，这意味着平台的下半场竞争指标变了：Marketplace 数量、构建分钟单价这些"上半场指标"让位给"门禁能否强制（分支保护 + required checks）、发布能否审批（Environments）、制品能否自证（attestations）、代理凭据能否隔离"。选型时应把这些下半场指标放进评估清单——它们恰好都是六环节闭环里"rollback 与留存验证"环节的现代化身。

对用户的判断与建议（综合两轴后的行动清单）：

1. 默认路径：代码已在 GitHub 的小团队，直接用 GitHub Actions 起步——lint/test/build 免费，发布制品进 Releases（不计配额、无上限）长存，中间产物显式设 retention-days 短留；回滚先用约定做法：re-deploy 旧 tag/commit（注意 re-run 旧 run 只是重放同一次 run，严格说不是回滚，见维度一）。
2. 规模化路径：发布规模变大或上了 K8s 后，加 Argo CD 接管 release/rollback 两环（git revert 即回滚，Git 历史即审计日志），CI 侧不必动——这是 2026 年最普遍的分工范式，也符合"分层实现闭环"的横向判断。
3. 一体化路径：需要私有化部署、跨阶段审计一体化的团队选 GitLab——六环节原生度最高（一键回滚按钮 + 内置双 registry + expire_in），自建 runner 不消耗配额使规模化成本可控；但注意 GitLab 制品默认只留 30 天，长存对象要显式进 Registry。
4. 三条红线：① 留存策略必须写进流水线定义（双层留存：发布制品长存、中间产物短留），不要吃平台默认值；② 成本模型显式纳入"自建 runner 是否计费"变量并每年复核（GitHub 2025-12 的收费尝试说明规则会变）；③ AI 生成的代码必须走与人完全相同的分支保护、必需检查与人工评审门，并为 CI 中的代理单独隔离凭据——否则 lint/test 门禁对"产量最大的提交者"形同虚设。
5. 不必焦虑锁定，但要为改写付费：流水线的逻辑结构可平移、语法需改写（GitHub Actions/GitLab/CircleCI 语法互不通用，主流平台提供官方迁移指南，如 GitLab Docs: Migrate to GitLab CI/CD），典型服务的 lint/test/build 段落改写约半天到一天（经验粗估、非实测）。GitHub Actions → +Argo CD → GitLab 的迁移路径互通，早期的最小闭环选择不会锁死后期的架构演进——前提是把"结构可平移"而非"配置可直接复用"作为迁移预期。

参考来源

说明：以下来源承接自两份章节报告（纵轴章与横轴章，检索日均为 2026-11-01），已去重合并；标注"当日直接抓取官方文档核实"者为横轴章核实项，综合环节未重新抓取；本次修订新增/更正的引用（npm provenance 公告、npm 官方文档、GitHub re-run 文档新路径、Buildkite 定价页、GitLab 迁移文档）已于 2026-11-01 当日实际抓取或检索核实（核实结果见文末「修订说明」）。原章节标注"未独立核验"的细节（Booch 1991 提法、《Accelerate》出版细节、Biome 时间线、SolarWinds 细节）在正文均随文保留标注；原列于其中的"npm SLSA Build L2 时间线"已由本次修订核验并更正，移出该清单。

章节来源

• 纵轴章：D:/CodexData/nightshift/output/reports/parts/2026-11-01-CICD流水线设计-最小闭环-vertical.md
• 横轴章：D:/CodexData/nightshift/output/reports/parts/2026-11-01-CI-CD流水线设计最小闭环-horizontal.md

CI/CD 历史与理论

• Wikipedia: CruiseControl · CruiseControl 官方站点 · Fowler《Continuous Integration》2006
• Jenkins 博客《Hudson's future》2011-01-11 · Kawaguchi @ artima · Jenkins 2016 年度总结（2.0 与 Pipeline as Code） · Jenkins Wiki: Pipeline as Code
• 《Continuous Delivery》O'Reilly 书目页（2010） · DORA《2014 State of DevOps Report》 · Puppet：DevOps 报告史

发布、回滚与 GitOps

• Fowler《BlueGreenDeployment》2010 · Fowler《CanaryRelease》2014
• GitOps/Argo CD 溯源 · Argo CD 概览
• GitLab 8.0 与 CI 集成（2015-12 官方博客） · GitLab 环境回滚与过时部署保护 · GitHub Docs: Re-run workflows and jobs（新路径，本次修订抓取核实）
• GitOps with Argo CD and GitHub Actions Explained（Medium，2026 年检索）——初稿仅检索摘要、未保留原始链接；本次修订检索可命中同名文章，但结果仅返回搜索跳转 URL，无法给出可直接点开的原始地址，故如实注明、保持无链接。

lint 与 build

• Zakas《Introducing ESLint》2013-07-16 · ESLint 关于页 · Ruff 仓库 · Astral 博客
• Docker 诞生与 CI/CD 影响 · Turborepo 仓库（Vercel 2022-04 收购） · TechCrunch 收购报道

托管 CI 与平台现状

• Travis CI quickstart · rOpenSci 迁移回顾 2020-11 · Wikipedia: CircleCI · Visual Studio Magazine 2019-08 Actions 报道
• JetBrains 2026-03 CI 工具调研（TeamCity 博客） · 2026 工具对比 · Jenkins 替代品对比：semaphore.io · northflank.com
• Drone vs Woodpecker 对比（2026-07 检索）——初稿仅检索摘要、未保留原始链接（本次修订检索可命中 2026-07-15 前后的同名主题文章，但结果仅返回搜索跳转 URL，无法给出可直接点开的原始地址）。· "Top 5 CI/CD Platforms for 2026"（2026-08）——同前，仅检索摘要、未保留原始链接。· Dagger/Tekton/Argo Workflows CI-as-code 对比（2026 年检索）——同前，仅检索摘要、未保留原始链接。
• GitLab Docs: Migrate to GitLab CI/CD（迁移指南枢纽，含 Jenkins/CircleCI 迁移子页）——本次修订新增（支撑"语法需改写、结构可平移"的迁移成本判断）；存在性经检索确认，直接抓取被站点防护重定向（403），未读取正文全文。

计费（标"当日直接抓取官方文档核实"者为横轴章 2026-11-01 核实项）

• GitHub Actions 计费（官方文档，当日直接抓取核实） · GitLab 计算分钟数（官方文档，当日直接抓取核实）
• GitHub Actions 定价风波 changelog 2025-12-16 · 官方定价说明 · HN 讨论
• GitLab 定价（搜索摘要引用，直接抓取超时） · CircleCI 定价 · Buildkite/TeamCity/Azure DevOps 定价对比 · Buildkite 官网定价页（本次修订补链，当日抓取 200；页面当前显示 Free $0（≤5 用户）/ Pro $30 每活跃用户/月 / Enterprise 定制三档，与正文"$0/$9/$19/$35 四档"口径不一致，以官网页面为准）

制品留存与供应链安全

• GitHub Docs：制品保留期 · retention-days changelog（2020-10-08） · actions/upload-artifact
• GitHub Releases 不计配额（About releases） · 社区讨论 #210936
• GitLab 制品 30 天默认过期与 expire_in · GitLab 管理设置
• SLSA 发布 HN 讨论（2021-06，仅用于 SLSA 框架发布的时间点） · npm 包 provenance 官方公告（2023-04-19，SLSA Build L2；本次修订补链，抓取 200） · npm 官方文档：生成 provenance 声明（本次修订补链，抓取 200） · GitHub Artifact Attestations GA（2024-06-25） · 制品 provenance 官方文档
• CERT-EU：XZ 后门公告 2024-032 · XZ 事件复盘

AI 代理与流水线

• StepSecurity：AI 代理进入 GitHub Actions 的风险 · DeployHQ：AI 代理与流水线

修订说明（2026-11-01，按独立审读意见逐条修订）

初稿共收到 8 条审读意见，逐条处置如下（行号为初稿行号）：

1. 【引文失配】原 L59：npm provenance 条目重写——时间由"2023 年 5 月"更正为"2023 年 4 月公开上线"（官方公告 2023-04-19），补两条官方链接（github.blog 公告、npm 官方文档，当日 curl 抓取均 200）；原误引的 SLSA 发布 HN 讨论（2021-06）仅保留在 2021 年 SLSA 发布处，不再为 2023 年论断背书。GA 时间点（2023-09）出自检索摘要，对应 changelog 链接抓取 404 未列出，已随文注明。
2. 【自相矛盾】原 L4 vs L162/L171/L176：卷首改为"绝大多数原始来源链接已保留"，不再声称"全部保留"；Buildkite 定价页补真实链接（当日抓取 200，页面口径与正文不一致处已在参考条目注明）；其余 4 条无链接条目（Medium GitOps、Drone vs Woodpecker、Top 5 CI/CD 2026、Dagger/Tekton 对比）逐条注明"仅检索摘要"及补链尝试结果。
3. 【范围承诺未兑现】原 L90/总表：对比框架句明确 Drone CI、Tekton、Argo Workflows "仅作背景提及、不入总对比表"（下表覆盖其余十一个对象）；"混合型"注释从类目尾部移到 Buildkite 名下。
4. 【承重论断无支撑】原 L125/L143："lint/test/build 的 YAML 高度可移植"降级为"流水线逻辑结构可平移、语法需改写"，补 GitLab 官方迁移文档为佐证（检索确认存在；直接抓取被站点防护 403 拦截），并给出粗略改写成本（典型服务 lint/test/build 半天到一天；Jenkins Groovy 数天；均标注为经验粗估、非实测）。行动清单第 5 条同步改写。
5. 【回滚叙述薄弱】原 L110（含 L96 总表、L118、L139 联动）：补 GitHub 官方 re-run 文档（新路径，当日抓取 200），讲清 re-run＝重放同一次 run（同一 commit、沿用原 workflow 版本、受保留期限制）≠ 回滚；re-deploy 旧 tag/commit 才是回滚及其风险（审批门重走、制品须仍在保留期内可复现）；re-deploy 约定标注"社区惯用，惯例普遍程度未独立核验"；小结补"并列第一梯队"判据一句话（六环节能否原生/低胶水闭合 vs 是否每环有原生按钮）；总表 GitHub Actions 行、维度五、行动 1 的表述同步修正。
6. 【TL;DR 冲突】原 L8：改为"中间产物显式设短保留期（平台 90/30 天默认只作兜底，而非默认策略）"，与洞察二、红线①一致。
7. 【数据无出处】原 L116：删除无来源链接、口径不明的"GitHub Actions ~85% vs Jenkins 59%→54%"数字，保留定性判断并在正文注明删除原因。
8. 【阶段与"六波"对应不齐】原 L14（及 L20/L26/L31/L52 涉及处）：在"口径先行"节补两点口径说明——六波与六阶段为近似对应（供应链与制品签名横跨阶段四/五，制品仓库潮内嵌于阶段二叙述）、四处标志性事件按主题归段（Fowler 2006-09 入阶段一、Hudson 2005 与 State of DevOps 2014 入阶段二、Vercel 收购 2022-04 入阶段四）；对应正文位置各加一处"见上文口径说明"指引，正文其余内容未删改。

本次修订实际核实的链接与结果：https://github.blog/2023-04-19-introducing-npm-package-provenance/（curl 200）；https://docs.npmjs.com/generating-provenance-statements（curl 200）；https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/re-running-workflows-and-jobs（curl 200；旧路径 /using-workflows/re-running-workflows-and-jobs 已 404）；https://buildkite.com/pricing（curl 200）；https://docs.gitlab.com/ci/migrations/（curl 403，被站点防护重定向至 sign_in，存在性经 WebSearch 检索确认）；npm provenance GA changelog（github.blog/changelog/2023-09-29-...，curl 404，未采用）。初稿 4 条无链接条目经检索可命中主题，但仅返回搜索跳转 URL，无法提供可点开原始链接。

*综合报告最终稿，撰写于 2026-11-01，按独立审读意见（8 条）修订。由纵轴章与横轴章综合而成；初稿保留于 drafts/ 目录作为修订输入，本稿为最终交付版本。*