誰才是世界上最好的 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，十分地方便。
誰才是世界上最好的 CI/CD 工具？
一萬個人眼中，有一萬個哈姆雷特。一萬個 CI/CD 使用場景中，也會適用於不同的 CI/CD 工具。那麼讀者你的使用場景是什麼呢？誰才是最適合你的使用場景的 CI/CD 工具呢？
閱讀更多 啟迪雲Tuscloud 的文章
