企业官网建设流程全解析

在CI/CD工具选型这个问题上，我见过太多团队花一周做对比PPT，最后因为一句“我们用Jenkins挺久了”就草草结束。Jenkins、Tekton、Arbess这三套工具的对比文章并不少，但多数停留在特性罗列，或者干脆是某家云厂商的产品软文。真正落到生产环境，你会发现工具之间的差距根本不在功能多寡，而在架构哲学和你所在团队的运维习惯是否匹配。

这篇文章从一个常年维护CI/CD平台的从业者视角出发，不玩概念，直接拆三样东西：第一，三套工具的内核设计到底差在哪；第二，同样一条发布流水线，用它们写出来的代码和体验有什么不同；第三，结合安装、插件生态、Kubernetes适配度、长期维护成本等硬指标，给出可以直接对号入座的选型建议。无论你是还在用Jenkins的老团队，还是刚起步、想直接上一套云原生流水线的新团队，这篇文章都值得你花十分钟看完。

1. 为什么这三套工具总被摆上同一张选型桌

1.1 Jenkins不是“不好用”，是“越好用越难养”

先说说Jenkins。它从海德森项目时代就开始积累，能活到今天，靠的不是界面漂亮，而是那个几乎无所不能的插件生态。你可以在Jenkins里构建Java、跑Python测试、扫描镜像、发钉钉通知、对接企业内部的工单系统……基本上没有它干不了的事。很多团队最初选Jenkins，就是因为“能搜到的经验最多，遇到问题不愁没人解答”。

但也正因为这样，Jenkins的系统复杂度会随着每个新插件的接入直线上升。我记得有一个项目，团队为了同时兼容三条产品线的发布流程，在Jenkins里装了四十多个插件，配置项互相引用，环境变量靠命名规范区分，最终结果是：能改流水线的人只有当初写Groovy脚本那位同事。后来这位同事离职，Jenkins成了全组不敢碰的“黑匣子”。

有人可能会说，这只说明你们规范没做好，跟Jenkins本身没关系。这句话有道理，但Jenkins的Master/Agent架构确实存在先天问题——所有配置、凭据、构建记录都存在Master上，Master是有状态的单点。哪怕现在你用Kubernetes插件动态创建Agent Pod，表面上是弹性架构了，但控制面依然要靠一个重状态的Jenkins Master兜底。磁盘损坏、Job配置丢失、插件版本升级互相打架，这些真实发生的场景，会持续消耗团队的运维精力。

1.2 Tekton代表的云原生化浪潮

Tekton是CNCF旗下的开源项目，它的核心思路很直白：既然大家都在Kubernetes里干活，那流水线本身也应该变成Kubernetes资源。你不需要再单独维护一台Jenkins Master，也不需要操心Agent的注册和连接，因为流水线的每一次运行，都由Kubernetes控制器通过Pod的方式拉起一个Task，跑完就销毁。

这个思路在当时是很激进的。以前我们习惯把CI/CD工具看成“独立系统”，而Tekton把流水线彻底变成了“集群里的一类对象”。你定义Pipeline、Task、Trigger，然后kubectl apply，剩下的调度、重试、日志收集，全部交给Kubernetes的生态来处理。这种玩法很贴合GitOps场景，尤其是那些已经用Argo CD做CD、用Git做唯一事实来源的团队，Tekton几乎是天然契合。

当然，Tekton没那么完美。它的学习曲线不像文档里写的那么平缓，YAML文件层层嵌套，一个稍复杂的流水线可能需要维护五六个CRD对象。如果不借助Tekton Dashboard或tkn命令行工具，新人上手会相当吃力。

1.3 Arbess瞄准的下一代工作流需求

Arbess相对前两者来说年轻许多，我注意到它的时候，也是在做一次Ops平台技术预研时翻到的一个新兴项目。它的定位很好理解：如果你觉得Jenkins太重、Tekton的YAML又太碎，Arbess想做的是那个“配置更轻、可视化更好、天生事件驱动”的中间选项。

按我拿到的资料和自己搭建集群的体验来看，Arbess的核心是把CI/CD流程抽象成一个有向无环图（DAG），每个任务节点负责一件独立的事，节点之间用依赖关系连接。这种方式的好处是流程意图非常清楚，哪怕是不懂CI/CD的同事，看到那张图也能知道代码从提交到上线经历了哪些阶段。它和Tekton不同的一点在于，Tekton强调“资源即流水线”，Arbess更强调“工作流即产品”，所以在UI、可观测性和触发器管理上，Arbess做了一些更具产品感的整合。

Arbess目前的生态规模确实没法跟Jenkins比，社区案例和生产实践也少，选它需要一点尝鲜的心理准备。但如果你所在团队规模不大，又想绕开Jenkins的历史包袱，直接在一个新的抽象层上构建发布体系，它值得纳入评测范围。

2. 先把架构底座看清楚：三种完全不同的流水线内核

2.1 Jenkins：一切皆插件的单体调度架构

Jenkins的架构说复杂也复杂，说简单也简单。它的控制面是那个叫Master的Java服务，负责管理Job配置、构建队列、负载分配、凭据、插件系统；执行面是Agent节点，通过SSH或JNLP协议连接Master，真正跑构建脚本、执行Shell命令。插件体系是Jenkins的灵魂，但它也是一把双刃剑——插件能给你无限扩展能力，同时把系统复杂度抬到无限高。

我在生产环境踩过一个比较深的坑是：某个安全插件升级后，为了兼容新版本API，间接要求另一个构建工具插件必须跟着升；升完之后，某个使用老式系统调用的小插件直接不可用了。那次故障排查了整整一个下午，最终的解决办法是回滚插件版本并固定版本号。从那以后，我给自己定了一条规矩：凡是Jenkins上的插件，升级必须走预发环境验证，绝不允许直接在Master上点“一键升级”。

这种单体调度架构还有一个隐性成本——备份和恢复。Jenkins的配置、凭据、构建记录都写在Master文件系统里，所以备份策略非常关键。很多团队习惯性把Jenkins当成“能跑就行”的服务，从不考虑它挂掉之后怎么重建。等真出问题的时候，才发现连Job列表都没法完整恢复。

2.2 Tekton：流水线即Kubernetes资源

Tekton把CI/CD重新定义为“Kubernetes资源编排”的一部分。它提供了一组CRD，包括Task（任务）、Pipeline（流水线）、TaskRun（某次任务执行）、PipelineRun（某次流水线执行）。当你要触发一次发布时，本质是创建一个PipelineRun对象，然后Tekton Controller监听到这个对象，按定义好的步骤依次在集群里创建Pod执行。

这种做法的好处是架构层面解决了“控制面单点”问题。你不必像Jenkins那样考虑Master高可用，因为Kubernetes的Controller本身就靠多副本保证。流水线状态也不存在一个私有数据库里，而是以CR对象的形式保存在Etcd中，任何支持Kubernetes API的监控、备份、恢复工具都能操作它。

同时，Tekton的步骤是以容器为单位的。你在Task里写的每个step，对应的都是一个独立容器镜像。这种方式让流水线的可移植性大大提高——本地开发用Kind或Minikube环境能跑同一套YAML，测试和生产环境也能跑同一套YAML，因为底层执行方式是一致的。

但我也要说Tekton不好的一面。它的概念分层很多：Task/Pipeline是定义，TaskRun/PipelineRun是执行，还有Workspace、StepTemplate、Sidecar、Policy等概念。想把一条流水线写得比较优雅，需要理解这些对象之间的血缘关系和生命周期。否则很容易出现一种情况：流水线能跑通，但没人说得清它为什么要配这么多参数。

2.3 Arbess：以事件与工作流为第一公民

Arbess的架构思路，我理解下来是“工作流引擎 + 云原生执行”。它把一套发布流程拆成工作流定义和任务实现两层：工作流负责描述“先做什么、后做什么、哪些可以并行”，任务实现负责真正执行具体动作，比如构建镜像、跑测试、调用Kubernetes Job、发通知等。

它和Tekton最大的不同在于抽象层级。Tekton把“Task”和“Pipeline”拆成Kubernetes资源，每个资源都有自己的Spec和Status；Arbess则更强调“从事件到工作流”的闭环。比如Git Push触发一个工作流，这个工作流内部包含若干节点，每个节点有一个输入和输出，节点之间靠依赖关系连接。这种模型在大脑里非常直观，画起来就是一张图，团队沟通成本很低。

从执行层面看，Arbess的调度器会解析工作流DAG，判断哪些节点可以并行，哪些必须等待前置节点完成，然后通过执行器在容器或Pod中运行任务。它的资源调度依赖Kubernetes，可以充分利用集群的弹性能力。

另外，Arbess的架构里，事件系统是头等重要的事。它不但支持Webhook、定时器、手工触发，还能接消息队列里的消息作为触发源。这一点如果做得好，能很好地覆盖“构建完成之后自动更新外部系统状态”这类场景。

2.4 架构差异带来的连锁反应

选工具不是选“最牛的”，而是选“能长期养得起的”。架构差异会直接决定你未来三年的运维体验。

用Jenkins，你要养的是Master服务、Agent网络、插件版本矩阵和一套备份恢复方案；用Tekton，你要养的是Controller的稳定性、CRD版本兼容、Workspace存储的空间分配和回收策略；用Arbess，你要面对的是一个相对新但抽象更完整的工作流平台，你需要跟紧它的版本迭代节奏，并且可能时不时调研一下新版本的兼容边界。

我个人的建议是：先想清楚你所在团队擅长维护哪种东西。如果你们对Kubernetes控制器比较熟，Tekton和Arbess都容易入手；如果你们团队骨子里是传统的“运维一台机器”思维，那Jenkins可能仍然是阻力最小的路。

3. 同样发布一个版本，三套工具的写法差距有多大

3.1 Jenkins Pipeline：Groovy让你自由，也让你付出代价

Jenkins最标准的现代化写法是流水线即代码，也就是Jenkinsfile。它用Groovy语言描述整个构建发布过程。下面是一个简化版示例：

pipeline { agent { label 'linux' } environment { IMAGE_TAG = "${env.BUILD_NUMBER}-${env.BRANCH_NAME}" } stages { stage('Build') { steps { sh 'docker build -t registry.example.com/app:${IMAGE_TAG} .' } } stage('Test') { steps { sh 'pytest tests/ -q' } } stage('Deploy') { steps { sh 'helm upgrade --install app ./deploy/charts --set image.tag=${IMAGE_TAG}' } } } }

看起来不算复杂，但一旦你在里面加了循环、条件判断、异常捕获、共享库函数，Groovy的灵活性和松散类型就会让代码变得不可预测。我见过有人把“获取变更集、分析提交消息、动态决定后续步骤”的逻辑全部写进Jenkinsfile，功能确实做到了，但代码长度超过一千行，评审的人根本无从下手。

如果你只是把Jenkins当成一个“构建机上执行命令”的工具，千万别在Groovy里写业务逻辑。灵活的工具只留给少数自律的人用，用在团队里，就需要通过模板和规范去约束。

3.2 Tekton：用一堆CRD换来的原生与复用

Tekton的写法比Jenkinsfile啰嗦，但它的表达方式是声明式的。同样是构建、测试、部署，你需要分别定义Task和Pipeline：

apiVersion: tekton.dev/v1 kind: Task metadata: name: build-image spec: params: - name: imageTag type: string steps: - name: build image: docker:stable script: | docker build -t registry.example.com/app:$(params.imageTag) . --- apiVersion: tekton.dev/v1 kind: Task metadata: name: run-tests spec: steps: - name: test image: python:3.11 script: | pip install -r requirements.txt pytest tests/ -q --- apiVersion: tekton.dev/v1 kind: Pipeline metadata: name: release-pipeline spec: params: - name: imageTag type: string tasks: - name: build taskRef: name: build-image params: - name: imageTag value: $(params.imageTag) - name: test taskRef: name: run-tests runAfter: - build

从代码量看，Tekton确实更费墨。但换来的是：每个Task都是独立可复用的单元，可以在不同Pipeline之间引用；每次执行的状态都是Kubernetes资源，用kubectl describe就能看到完整状态流转；参数通过params传递，不像Groovy里的全局上下文那么随意。

不过Tekton的YAML也不是没坑。当你使用Workspace缓存Maven依赖或pip缓存时，需要仔细处理PVC的分配。如果你的任务很多，每个Pod都重复拉取相同的基础镜像，集群的网络IO可能会成为瓶颈。还有result的传递，跨Task传递字符串结果时，需要理解Tekton result的语义，否则会出现结果被截断之类的问题。

3.3 Arbess：把发布编排当成一张有向无环图

Arbess在表达方式上更接近“工作流编排”。我没有公开的官方配置可以直接照抄，这里按我实际理解给出一个结构示意：

workflow: name: release trigger: event: push branches: ["main"] tasks: - name: build action: buildkit params: image-tag: "${trigger.commit-sha}" - name: test action: test-runner dependsOn: ["build"] - name: deploy action: helm-deploy dependsOn: ["test"] params: release-name: app namespace: production

注意一下，这里每个节点都有dependsOn来声明依赖，一眼就能看出流程顺序。尤其是并行节点多的时候，这种图式表达的直观感是线性脚本没法比的。如果某个团队希望让产品经理也能看得懂部署流程，Arbess这类工作流表达方式明显更友好。

当然，这种高度抽象也意味着你最好使用平台内置的Action集合，如果某个自定义动作没被封装，你需要自己动手开发。Arbess目前在这方面的素材库没有Jenkins插件生态那么丰富。

3.4 三种表达方式背后的协作隐喻

用一种直白的方式总结这三种写法的差异：Jenkins让你写“讲清楚每一步做什么的剧本”，Tekton让你定义“符合集群规范的资源清单”，Arbess让你绘制“展示任务依赖关系的流程图”。

剧本写得好，执行最灵活，但依赖写剧本的人长期维护；资源清单最标准，可复用性最强，但学习成本都在YAML细节里；流程图最直观，跨角色沟通最顺畅，但你要接受新工具不成熟带来的局限性。选哪种表达方式，其实就是选团队习惯的协作模式。

4. 硬碰硬核心维度：安装、生态、维护成本横向对比

4.1 一张对比表快速扫盲

这里我不聊宣传口径，只聊我实际部署和日常使用中感知到的差异。

安装这块，Jenkins是我踩坑最多的地方。下载war包、配置JDK版本、初始化管理员密码、安装插件……每一步都有可能出现意外。对于国内团队来说，插件下载是个绕不开的问题。默认插件源在部分环境里下载很慢，解决办法是配置镜像站。这里我建议团队直接把Update Center地址换成可靠的镜像仓库地址，能省很多事。另外好多人问Jenkins汉化的问题，其实就是装一个localization插件的事，界面就能切中文，但实际体验上很多子页面依然是英文，没必要在这上面花太多精力。

还有两个很常见的Jenkins问题顺便提一下。一个是容器内使用Docker命令，也就是大家常说的DinD问题。实际生产里我强烈不建议使用特权模式启动容器，更不建议直接挂载宿主的/var/run/docker.sock，因为安全边界会很模糊。要用就用Kaniko或者BuildKit的Rootless模式，在Kubernetes里构建镜像才是正路。另一个是Jenkins配置Kubernetes集群，用Kubernetes插件动态拉起Agent Pod确实能解决部分弹性问题，但如前所说，Master这个“大象”本身还要继续养好。

4.2 Tekton和Arbess的运维重心完全不同

Tekton落地后，你真正要关注的运维点是：Controller所在的命名空间资源占用是否正常，CRD版本是否与Kubernetes大版本兼容，以及清理PipelineRun遗留下来的PVC和Pod。默认情况下，每次运行都会留下对应的Pod和PVC，如果不设清理策略，集群里会堆积大量残留资源。所以从第一天开始就要考虑对旧PipelineRun做定期清理。

Arbess的运维重心和Tekton有点像，但因为它起步晚，更要注意版本兼容性。新工具迭代频率往往不低，API变动、CRD调整、配置文件格式调整都可能发生。我的建议是如果决定用Arbess，不要轻易升级到最新版本的中小版本，先在预发环境验证，确定没问题再滚动到生产集群。任何新工具都有类似的成长阵痛期，这不是黑它，是经历过的人都会明白的现实。

4.3 插件生态的“拥有成本”比想象的更隐蔽

Jenkins的插件数量庞大，但数量本身不是壁垒，真正要命的是插件之间的兼容性。你装的插件版本相差甚远时，Jenkins的依赖解析会让人非常头疼。所以我建议所有Jenkins重度用户都维护一份插件版本锁定清单，升级之前优先看依赖树，而非直接点更新。

Tekton Catalog相比Jenkins插件数量少很多，但Catalog的方式更干净，每个Step都是标准容器镜像，不存在插件之间互相“污染”的问题。Arbess的Action成熟度还依赖于作者和社区贡献，目前引入新Action的体验更像“搭积木”，还达不到“什么都有”的程度，需要一点自己做轮子的心理预期。

5. 对号入座的选型决策与几条换工具前的避坑忠告

5.1 我会坚持用Jenkins的团队类型

如果你的团队已经在Jenkins里沉淀了大量Job、共享库、私有插件，并且大家平时用得挺顺手，我劝你不要轻易提迁移。工具选型最怕的就是“为了换而换”，尤其当Jenkins背后还有一套成熟的内部流程和操作习惯时，迁移的地基不是技术，而是组织认可度。

这类团队真正该做的是：给Jenkins瘦身，定插件准入标准，把Jenkinsfile做成模板，把公共逻辑收拢到共享库。把Master改成高可用部署，备份策略做扎实。只要控制住复杂度，Jenkins再战三年毫无问题。

5.2 我会优先选Tekton的团队类型

如果团队已经全面Kubernetes化，CD侧已经用Argo CD这类GitOps工具，CI侧还没有一个“符合集群原生气质”的答案，那Tekton就是很自然的选择。它能和Argo CD无缝联动：Tekton负责构建并推送镜像，更新Git仓库里的部署清单，Argo CD自动同步到集群。这种闭环天然就能落地。

选Tekton的团队最好具备一定Kubernetes排障能力，因为你的流水线问题实际上变成了一堆Pod、CRD、RBAC、PVC的问题。但这也是优势——排查流水线和排查应用一样，用同一套思维和工具链。

5.3 值得为Arbess赌一把的团队类型

如果你是从零搭建CI/CD平台，团队结构精干，对Kubernetes有一定基础但不打算维护一整套复杂CRD体系，而且产品场景里确实有很多“事件触发流程”“定时巡检”“异步通知”这类需求，那Arbess可以小范围试点。

试点方式很关键：不要一下子把核心产品的发布都押上去，先挑一个低频内部工具的部署流程跑通，验证稳定性、日志、权限模型是否满足预期。跑两三个月，确认没问题后再逐步扩大范围。新工具不是不能用，而是要用小步快跑的方式降低试错成本。

5.4 换工具前不解决会翻车的四件事

第一，统一环境入口和凭据管理。不管换到哪个工具，Git仓库地址、镜像仓库地址、云厂商AK/SK、Kubernetes kubeconfig这些凭据必须有一套统一的注入和轮换机制。没有统一凭证管理，换工具只是把散落的账号换个地方继续散落。

第二，想清楚制品和缓存谁来管。Jenkins的workspace、Tekton的Workspace PVC、Arbess的节点本地存储，本质都是同一类问题：构建中间产物和依赖缓存的归属。换工具之前，先用一个共享OSS/S3存储把构建产物和依赖缓存收拢好，工具迁移会顺畅很多。

第三，不要把旧流水线逐行翻译。从Jenkins迁移到Tekton或Arbess时，最忌讳的就是拿Jenkinsfile里的stage结构套到新工具里面，逐段翻译。这等于用新的瓶子装旧酒，结果往往是既没体现新架构优势，又把旧逻辑的复杂性原封不动带了过去。正确做法是先梳理业务需要的阶段和产物，再按新工具的原生模型重新设计。

第四，定义最小化流程规范和评审机制。无论哪个工具，流水线一旦可以被任意修改，早晚会变得无人能维护。我建议在选型落地时就约定：流水线定义必须单独建仓库，必须走PR评审合并，禁止直接在线上平台里编辑配置。这个规矩在哪个工具上都适用。

5.5 最后说点实在话

我自己的体会是，CI/CD工具选型从来不是一个单纯的技术判断题，更像是一个组织匹配题。Jenkins、Tekton、Arbess哪个更强，脱离了团队现状去谈没有意义。与其花几周时间做华丽的功能对比表，不如拿一个月的真实项目，把三种工具各搭一套最小流水线，跑一遍从提交到部署的完整链路，看看哪个最像你们日常工作的方式，那就是答案。

另外，不管最后选了谁，都记得在一开始就写好流水线模板，把环境变量、参数、权限、通知这些公共逻辑收敛到统一的地方。很多团队日后痛苦的根源不是工具不行，而是没有在早期建立约束。工具只是骨架，模板和规范才是让流水线真正可长期维护的血肉。