本文目录导读：
CI/CD领域一直在快速发展，除了我们熟知的Jenkins、GitLab CI、CircleCI、Travis CI 等经典工具外，近年来涌现了许多新工具，它们通常更专注于云原生、容器化、高性能、低资源消耗或更简化的配置。
以下是一些值得关注的新兴/迭代较快的CI/CD工具,按类别划分：
云原生与容器化时代的代表
这些工具专为Kubernetes和微服务架构设计,通常轻量且易于集成。
- Argo CD：GitOps 的黄金标准，它不是一个传统的 CI 工具，而是专注于 CD（持续部署），它能将 Kubernetes 集群的当前状态与 Git 仓库中定义的期望状态进行同步，目前非常火爆,是云原生部署的首选。
- Tekton：CNCF（云原生计算基金会）毕业项目，它是一个 Kubernetes 原生的 CI/CD 框架，提供标准的 CRD（自定义资源定义）来定义流水线（Pipeline）、任务（Task）等，灵活性极高,但学习曲线较陡。
- Flux：与 Argo CD 齐名的 GitOps 工具，它同样专注于自动同步，但更强调“无状态”和可扩展性，V2 版本（Flux v2）支持多租户、密钥管理和通知。
- Woodpecker CI：一个轻量级、开源、基于容器的工作流引擎，它非常专注于使用 Docker 容器作为构建步骤（Plugin），配置简单，社区活跃，适合不想用重量级 Jenkins 或复杂 Kubernetes 原生工具的用户。
SaaS 与 平台工程 方向的新兴选择
这些工具倾向于提供更现代的 UI、更简单的配置（YAML）、更好的开发者体验（DX）。
- Dagger：以代码驱动的 CI/CD，它让你用 Go、Python、TypeScript 等编写一个统一的 SDK，然后可以在本地或任何 CI 平台上运行，它解决了“环境一致性”问题，让你的 CI 流程和本地开发环境完全一致，非常新潮,但还在快速迭代中。
- GitHub Actions：虽然不是全新的，但其 Hyscale（自托管运行器） 和 GitHub Actions 市场 的生态在过去两年中爆发式增长，它非常适合 GitHub 用户,无需额外搭建服务器。
- Buildkite：混合 CI/CD 模型，你只需要一个 Agent 在你的服务器上运行，而编排（Pipeline、UI）由 Buildkite 托管，它结合了 SaaS 的便利性和自我托管的安全/性能优势,非常受大型公司欢迎。
- Cirrus CI：以灵活性著称，它支持运行在 Kubernetes、GCP、AWS、Azure 甚至你自己的免费 Mac 上，配置方式独特（使用 YAML 和自定义语法）,社区活跃。
- Earthly：一个“Makefile 和 Docker 的混合体”，它让你定义构建步骤，并自动将每个步骤作为独立容器运行，它能保证在本地、CI 甚至其他开发者机器上获得完全一致的构建结果,对于多语言项目特别有用。
面向特定场景和语言的工具
- Turborepo / Nx：单体仓库（Monorepo）的 CI 加速器，它们不是传统 CI 工具，而是构建系统，通过智能缓存（只重建有变化的包）、任务编排和依赖图分析，大幅减少 CI 时间，配合其他 CI 工具（如 GitHub Actions）使用效果极佳。
- Jefferson（已更名为 PipeCD）：一个为 Kubernetes、Terraform、Cloud Run、Lambda 等提供GitOps支持的持续交付平台,提供声明式部署和回滚。
- Drone CI / Harness CI：Drone 是经典的基于容器的 CI 工具，发展平稳，Harness 是商业软件，主打 AI 驱动的部署、健康检查和自动回滚,算力成本较高但功能强大。
总结与建议
| 你的需求 | 推荐关注的新工具 |
|---|---|
| 云原生 / K8s 部署 | Argo CD（CD）、Flux、Tekton（CI+CD） |
| GitOps 狂热者 | Argo CD、Flux |
| 极度轻量 / 简单 | Woodpecker CI、Earthly、Dagger |
| SaaS 体验 + 自托管控 | Buildkite |
| 单体仓库加速 | Turborepo、Nx |
| 极致的可编程性 | Dagger |
| 不想折腾服务器 | GitHub Actions、Cirrus CI |
一句话建议：
- 如果你玩 K8s，Argo CD 几乎是必学的。
- 如果你想用一种工具搞定本地和 CI 的构建，尝试 Dagger 或 Earthly。
- 如果你只是想要一个简单、免费、开源且足够用的项目 CI，Woodpecker CI 是不错的选择。
这些工具的发展日新月异，建议你根据团队技术栈（K8s vs 传统服务器 vs Serverless）、对复杂度的容忍度以及对 GitOps 的接受程度来选择。
