在搭建 DevOps 工具链时，Jenkins、GitLab CI 与 Argo CD 是经常被放在一起比较的三个工具，但很多团队在选型时容易混淆它们的边界。这三者并不完全是同一层级的替代品：Jenkins 是通用自动化平台，GitLab CI 是代码仓库内置的 CI/CD 能力，而 Argo CD 是 Kubernetes 原生的持续交付工具。理解它们的定位差异，是做出有效选型的前提。
先明确边界：CI 与 CD 不是一回事
持续集成（CI）关注代码合并后的构建、测试与静态检查，目标是快速反馈；持续交付/部署（CD）关注将构建产物部署到目标环境。Jenkins 和 GitLab CI 都能做 CI，也具备一定的 CD 能力，但 Argo CD 专注 Kubernetes 环境的持续交付，采用 GitOps 模式，以 Git 仓库作为声明式配置的唯一事实来源。如果团队使用 Kubernetes，Argo CD 常与 CI 工具配合，形成完整的 CI/CD 链路。
Jenkins：灵活但需自建
Jenkins 是历史最悠久的开源自动化服务器，插件生态极其丰富，几乎可以集成任何工具。它的优势在于灵活性：通过 Pipeline 脚本（Jenkinsfile）可以编排任意复杂的流程，适合异构环境或遗留系统。但灵活性也带来维护成本，Jenkins 需要自己管理主节点和代理节点，插件兼容性问题也时有发生。
适用场景：已有大量插件投资、需要自定义构建环境、或团队熟悉 Groovy 脚本。
失败条件：团队缺乏运维 Jenkins 的精力，或项目规模小但追求开箱即用。
GitLab CI：一体化与内置体验
GitLab CI 与 GitLab 代码仓库深度集成，使用 .gitlab-ci.yml 定义流水线，配置简单直观。它天然支持 Merge Request 流水线、环境看板和部署保护，适合已经在使用 GitLab 的团队。GitLab CI 也支持 Kubernetes 集成，但 CD 能力相对基础，复杂部署策略（如金丝雀、蓝绿）需要额外配置。
适用场景：团队使用 GitLab 作为代码托管平台，希望减少工具链组件，快速搭建 CI。
失败条件：需要精细的部署策略或跨多个 Kubernetes 集群管理时，GitLab CI 的 CD 能力可能不够。
Argo CD：GitOps 持续交付
Argo CD 是 CNCF 项目，以 Git 仓库为唯一事实来源，自动同步应用状态到 Kubernetes 集群。它提供可视化界面、回滚、多集群管理和策略（如自动同步、Self-Heal）。Argo CD 本身不做 CI，它等待镜像更新或手动同步，通常与 CI 工具配合：CI 构建镜像并推送，Argo CD 检测到新镜像后部署。
适用场景：应用已容器化并部署在 Kubernetes，团队希望采用 GitOps 实践。
失败条件：非 Kubernetes 环境、或团队不愿意维护 Git 仓库中的部署清单。
组合使用：以 CI + GitOps 为例
一个常见的实践是：GitLab CI 负责构建和测试，Argo CD 负责部署。具体流程为：代码推送到 GitLab，触发 CI 流水线，构建镜像并推送到镜像仓库，然后更新 Git 仓库中的部署清单（如镜像标签），Argo CD 检测到变更后自动同步到集群。这种组合兼顾了 CI 的灵活性和 CD 的声明式管理。
如果团队已使用 Jenkins，也可以保留 Jenkins 做 CI，通过插件触发 Argo CD 同步，但集成成本略高。
选型决策思路
- 如果团队已有 GitLab，且部署目标简单，优先考虑 GitLab CI 的 CD 功能。
- 如果团队使用 Kubernetes 且重视 GitOps，将 Argo CD 作为 CD 层，CI 工具可选 Jenkins 或 GitLab CI。
- 如果团队需要高度自定义的流水线，或已有大量 Jenkins 插件，选择 Jenkins 作为 CI 引擎。
可观测性：工具链的必经之路
无论选择哪种工具链，都需要关注流水线的可观测性。Prometheus 是云原生监控的事实标准，可采集构建指标（如任务耗时、成功率）和集群状态；OpenTelemetry 提供统一的遥测数据标准，可将流水线中的 trace 与日志关联。建议在搭建工具链时，同步规划监控与日志收集，否则故障排查将非常困难。
参考资料
延伸阅读