谁才是世界上最好的 CI/CD 工具？

查看原文

其他

谁才是世界上最好的 CI/CD 工具？

Original: 韩骏 CSDN 2019-06-22

作者 | 韩骏

责编 | 胡巍巍

出品 | CSDN（ID：CSDNnews）

谁才是世界上最好的 CI/CD 工具？TeamCity、Jenkins、Travis CI、AppVeyor 或是 Azure Pipelines ？

在回答这个问题之前，笔者想先问问大家，什么是世界上最好的语言？PHP、Java、Python、JavaScript或是C++ ？笔者想说，都不是！不同的场景适合用不同的语言，不谈业务场景而讨论哪个语言好，都是耍流氓！

· 嵌入式：如果是在内存小于 128 KB 的 MCU 上，相信 C 一定是你的首选。

· Web 前端：毋庸置疑，JavaScript 一定是绝大多数开发者的最爱。

· 高并发：高并发场景下，Java 或是 Go 应该是个不错的选择。

看到这里，相信读者已经明白，和编程语言一样，如果要讨论最好的 CI/CD 工具，一定是要分具体的业务场景。不同的 CI/CD 工具适合于不同的场景。只有考虑清楚实际的使用场景，才能选出最合适的 CI/CD 工具。那么，我们就来看看不同的 CI/CD 工具各种有哪些优势呢？

On-Premise vs Hosted

On-Premise 需要用户搭建自己的服务器来运行 CI/CD 工具，而Hosted CI/CD 工具是一个 SaaS 服务，不需要用户搭建自己的服务器。

TeamCity 和Jenkins 属于 “On-Premise” 阵营，Travis CI 属于 “Hosted” 阵营，而 AppVeyor 和 Azure Pipelines 则是既能 “On-Premise” 又能 “Hosted” 。

如果你在 CI/CD 过程中，你需要连接到不同的内网服务。那么 On-Premise 的 CI/CD 工具适合这样的使用场景，你可以把 Build Agent 部署在内网的机器上，这样可以轻松地连接内网资源。

如果你不需要连接内网资源，那么 Hosted CI/CD Service 就是你的最佳选择了，有以下几个优势。

· 维护成本：Hosted CI/CD Service 可以说是零维护成本了，整个运行环境都由服务商托管。相比于 On-Premise 的CI/CD 工具，使用者需要自己花大量时间搭建与维护服务器，对于 Hosted CI/CD Service 来说，使用者完全不需要担心背后服务器的维护。

· Clean的运行环境：假设你在为你的 Python 项目寻求一个 CI/CD 工具，而你的 Python 项目需要同时对 Python 2.7, 3.6, 3.7 进行持续集成，那么 Hosted CI/CD Service 完全可以满足你的需要。On-Premise 的机器上，你需要对不同的 Python 版本而烦恼，而 Hosted CI/CD Service 每次都会创建一个新的运行环境，想用哪个 Python 版本就用哪个。

· 预装的软件和运行时：每一个项目在做持续集成时，往往会需要依赖不同的运行时和工具链，Hosted CI/CD Service 会帮你预装好许多常用的软件和运行时，大大减少了搭建环境的时间。

价格

价格成本也是我们在技术选型要重点考虑的一点。先来看看 On-Premise 的 TeamCity 和 Jenkins，虽然他们都是免费使用的，但是使用者都需要搭建自己的服务器，不论是用自己的物理机还是使用 Azure 或是 AWS 上的虚拟机，这都是一个花费。

On-Premise 的 TeamCity 和 Jenkins 看似免费，其实用户需要在服务器上有很大的花费，特别是对于大规模的持续集成的需求下，这会是个很大的价格成本。如果是对于开源项目，Hosted CI/CD Service 有着很大的优势，Travis CI、AppVeyor 和 Azure Pipelines 对于开源项目都是完全免费的。

对于私有项目，Travis CI 和 AppVeyor 是收费的，而 Azure Pipelines 有一个月 1800 分钟的免费额度。可见，对于私有项目，Azure Pipelines 有很大的优势。

插件

牛顿曾经说过：如果说我看得比别人更远些，那是因为我站在巨人的肩膀上。

这些 CI/CD 工具的插件就是我们的巨人，这些插件把繁琐复杂的 CI/CD 流程化繁为简，极大地方便了我们使用。Jenkins、TeamCity 和 Azure Pipelines 都有丰富的插件支持，而 Travis CI 和 AppVeyor 则是没有的。

从插件数量来看，Jenkins 有超过 1600 个插件，Azure Pipelines 有 970 个插件，TeamCity 则是 366 个插件。Jenkins 的插件生态还是相当强大的。所以，从插件角度来看，Jenkins 会是首选。

SCM Support

Jenkins、TeamCity、Azure Pipelines 以及 AppVeyor 都支持不同种类的源代码管理工具（SCM）：GitHub, GitHub Enterprise, Bitbucket, GitLab, Azure Repos, Kiln 以及custom repos 等等。而 Travis CI 却只支持 GitHub，这是它的一大软肋。

OS support

曾经，在很长的一段时间里，在主流的 Hosted CI/CD Service 中，Travis CI 只支持 Linux 和 macOS，而 AppVeyor 只支持 Windows。

所以大家经常会在一些开源项目上看到，一个项目同时使用了 Travis CI + AppVeyor 的配置。

早年，最火的开源项目之一 VS Code 也是如此。然而，去年 Azure Pipelines 的横空出世，打破了这种局面。

Azure Pipelines 支持 Linux、macOS 和 Windows，使得开发者可以只使用一个 Hosted CI/CD Service 就能在三种 OS 上进行持续集成。

不久后，VS Code 也切换到了 Azure Pipelines 上。也许正是因为 Azure Pipelines 的出现，使得 Travis CI 和 AppVeyor 感到了压力，Travis CI 在不久后宣布支持 Windows（预览版），而 AppVeyor 也支持了 Linux。

曾经有那么几个月，在操作系统的支持上，Azure Pipelines 是有着巨大优势的。而如今，Travis CI 和 AppVeyor 都已经缩小了和 Azure Pipelines 的差距。

UI first vs YAML first

TeamCity、Jenkins、Travis CI、AppVeyor 和 Azure Pipelines 都支持以 YAML 文件来定义持续集成的配置。

通过 YAML 文件来定义，灵活性和可扩展性都很强。然而，对于初学者来说 YAML 文件的配置有一定的学习曲线。TeamCity、Jenkins 和 Azure Pipelines 支持用过 UI 界面的方式来定义持续集成的配置，大大降低了初学者的学习成本。

Cron job

在一些 CI/CD 的使用场景中，我们有时会需要在某个时间点来触发持续集成，比如每个工作日的早上八点进行持续集成。

这时，我们就是需要有 cron job 的支持。在 cron job 的支持上，AppVeyor 做的最好，它支持标准的 Crontab 语法，使用者可以灵活地定义所需要的持续集成触发时间。

Trouble shooting

有些时候，我们运行持续集成的 Build Agent 会出现问题，或者我们希望能直接登录到 Build Agent 对失败的持续集成进行问题排查。

对于 On-Premise 的 TeamCity 和 Jenkins，由于机器是用户自己搭建的，用户可以方便地登录到自己的机器进行问题排查。

而 Hosted CI/CD Service 的机器是由第三方托管的，要进行问题排查，是比较难的。

而 AppVeyor 却能让用户直接登录到 Build Agent 进行问题排查。通过 RDP 可以登录到 Windows 的 Build Agent，通过 SSH 可以登录到 Linux 的 Build Agent，十分地方便。