推薦一些頂級的開源CI/CD工具

作者 | Dan Barker

譯者 | 謝麗

CI/CD 實踐對於基礎設施、第三方應用程式和內部開發的應用程式同樣適用。雖然有許多不同的工具可以實踐 CI/CD，但這些工具都使用類似的模型。最重要的也許是，引導公司采取這種新的做法會讓你在公司裡處於一個強有力的地位，成為別人前進的燈塔。

持續集成、持續交付和持續部署（CI/CD）在開發社區中已經存在多年。有些組織已經有相應的運營工具，但許多沒有。對於大多陣列織來說，運營團隊必須像開發團隊一樣熟悉 CI/CD 工具和實踐。

CI/CD 實踐對於基礎設施、第三方應用程式和內部開發的應用程式同樣適用。雖然有許多不同的工具可以實踐 CI/CD，但這些工具都使用類似的模型。最重要的也許是，引導公司采取這種新的做法會讓你在公司裡處於一個強有力的地位，成為別人前進的燈塔。

讓我們更深入地研究下這些工具。我們將對每一個工具進行簡要地介紹，並分享可以讓你了解更多資訊的鏈接。

GitLab CI

項目頁面：

https://about.gitlab.com/product/continuous-integration/

源代碼：

https://gitlab.com/gitlab-org/gitlab-ce/

遵循 MIT 許可協定

GitLab 是 CI/CD 領域的一個新手玩家，但它已經在 Forrester Wave 持續集成工具中佔據了領先地位。在這樣一個競爭對手眾多而水準又很高的領域，這是一項巨大的成就。是什麽讓 GitLab CI 如此了不起？

它使用 YAML 檔案來描述整個管道。

它還有一個功能叫 Auto DevOps，使比較簡單的項目可以自動構建內置了若乾測試的管道。

使用 Herokuish 構建包來確定語言以及如何構建應用程式。有些語言還可以管理數據庫，對於構建新的應用程式並在開發過程一開始就將其部署到生產環境中，這是一個很重要的功能。

提供到 Kubernetes 集群的原生集成，並使用多種部署方法的一種（如基於百分比的部署和藍綠部署）將應用程式自動部署到 Kubernetes 集群中。

除了 CI 功能之外，GitLab 還提供了許多補充功能，比如自動把 Prometheus 和你的應用程式一起部署，實現運行監控；使用 GitLab 問題（Issues）、史詩（Epics）和裡程碑（Milestones）進行項目組合和項目管理；管道內置了安全檢查，提供跨多個項目的聚合結果；使用 WebIDE 在 GitLab 中編輯代碼的能力，它甚至可以提供預覽或執行管道的一部分，以獲得更快的反饋。

GoCD

項目頁面：

https://www.gocd.org/

源代碼：

https://github.com/gocd/gocd

遵循 Apache 2.0 許可協定

GoCD 出自 Thoughtworks 的大師之手，這足以證明它的能力和效率。對我來說，GoCD 與其他工具的主要區別在於它的價值流圖（VSM）特性。事實上，管道可以與管道連接在一起，為下一條管道提供“材料”。這使得部署過程中具有不同職責的團隊更加獨立。在希望保持團隊隔離性的舊組織中引入這種類型的系統時，這可能是一個有用的特性，但是，讓每個人都使用相同的工具，以後會更容易發現 VSM 中的瓶頸，那樣就可以重新組織團隊或工作以提高效率。

為公司的每個產品都配備 VSM 是非常有價值的；GoCD 允許在版本控制系統中以 JSON 或 YAML 的形式對其進行描述，並以可視化的方式顯示所有有關等待時間的數據，這使得這個工具對於想更好地理解自己的組織的人更有價值。從安裝 GoCD 開始，只需要借助手動審批門（manual approval gates）就可以完成流程映射。然後讓每個團隊使用手動審批，這樣你就可以開始在可能存在瓶頸的地方收集數據。

Travis CI

項目頁面：

https://docs.travis-ci.com/

源代碼：

https://github.com/travis-ci/travis-ci

遵循 MIT 許可協定

Travis CI 是我第一次使用軟體即服務（SaaS） CI 系統，它非常棒。管道以 YAML 的形式存儲在源代碼中，可以與 GitHub 等工具無縫集成。我不記得上一次由於 Travis CI 或集成而導致管道失敗是什麽時候了——Travis CI 的正常運行時間非常長。它不僅可以作為 SaaS 使用，而且還有一個可以託管的版本，我還沒有運行這個版本，因為它有很多組件，安裝起來似乎有點困難。

我覺得，用 Travis CI 提供的 Helm Charts 將它部署到 Kubernetes 會容易得多。這些 Chart 並沒有把所有內容都部署，但我相信，它未來可以部署更多內容。如果你不想自己處理這些麻煩，還有一個企業版本。

但是，如果你正在開發開源代碼，那麽就可以免費使用 Travis CI 的 SaaS 版本。這是一個很棒的團隊提供的很棒的服務！這會大幅降低開銷，並且允許你使用一個相當通用的平台來開發開源代碼，而無需運行任何東西。

Jenkins

項目頁面：

https://jenkins.io/

源代碼：

https://github.com/jenkinsci/jenkins

遵循 MIT 許可協定

Jenkins 是 CI/CD 領域中一款最早的、久負盛名的工具，是事實上的標準。對於大多數非開發人員來說，Jenkins 可能會是一個不小的負擔，並且長期以來也一直是其管理員的負擔。然而，這些都是他們想要解決的事項。

Jenkins 配置即代碼（JCasC）應該有助於解決困擾管理員多年的複雜配置問題。和其他 CI/CD 系統類似，它允許通過 YAML 檔案實現 Jenkins 主節點的零接觸配置。Jenkins Evergreen 的目標是通過提供基於不同用例的預定義 Jenkins 配置來簡化這個過程。這些發行版應該比標準的 Jenkins 發行版更容易維護和更新。

Jenkins 2 引入了具有兩種管道類型的原生管道功能。當你在做一些簡單的事情時，這兩種方法都不像 YAML 那麽容易操作，但是它們非常適合處理更複雜的任務。

Jenkins X 是 Jenkins 的徹底轉變，很可能是原生雲 Jenkins 的實現（或者至少是大多數用戶在使用原生雲 Jenkins 時會看到的東西）。它將使用 JCasC 和 Evergreen，並在 Kubernetes 本地以最佳的方式使用它們。對於 Jenkins 來說，這是激動人心的時刻，我期待著它在這個領域的創新和持續的長官地位。

Concourse CI

項目頁面：

https://concourse-ci.org/

源代碼：

https://github.com/concourse/concourse

遵循 Apache 2.0 許可協定

我第一次聽說 Concourse 是通過 Pivotal Labs 的同事介紹的，那是一個早期的 Beta 版本——當時還沒有多少類似的工具。該系統由微服務組成，每個作業在一個容器中運行。它獨家提供的一個最有用的特性是：從本地系統（可進行本地修改）運行一項作業的能力。這意味著你可以在本地進行開發（假設你已經連接到 Concourse 伺服器），並像在實際構建管道中那樣運行構建。此外，你還可以從本地系統重新運行失敗的構建，並注入特定的更改來測試修複程式。

Concourse 還有一個簡單的擴展系統，它以資源這個基本概念為基礎。基本上，你希望向管道提供的每個新特性都可以在 Docker 鏡像中實現，並作為新的資源類型包含在配置中。這使得所有的功能都封裝在一個單一的不可變工件中，可以獨立地更新和修改，而破壞更改並不一定要同時破壞所有的構建。

Spinnaker

項目頁面：

https://www.spinnaker.io/

源代碼：

https://github.com/spinnaker/spinnaker

遵循 Apache 2.0 許可協定

Spinnaker 來自 Netflix，它更側重於持續部署而不是持續集成。它可以與其他工具集成，包括 Travis 和 Jenkins，以啟動測試和部署管道。它還集成了 Prometheus 和 Datadog 等監控工具，根據這些系統提供的指標可以進行部署決策。例如，金絲雀部署使用判斷的概念和收集的指標來確定最新的金絲雀部署是否導致了相關指標的下降，是否應該回滾，或者是否可以繼續部署。

與部署相關的一些額外的、獨特的特性涵蓋了我們在討論持續部署時經常忽略的一個領域，甚至可能看起來正相反的領域，但對於成功來說卻至關重要：Spinnaker 可以使持續部署不那麽持續。它可以阻止某個階段在特定時間運行，從而防止部署在應用程式生命周期的關鍵時刻發生。它還可以強製手動審批，以確保在業務可以從更改中獲得最大收益的時候發布。事實上，持續集成和持續部署的全部要點是準備好在業務需要更改時盡快部署變更。

Screwdriver

項目頁面：

http://screwdriver.cd/

源代碼：

https://github.com/screwdriver-cd/screwdriver

遵循 BSD 許可協定

Screwdriver 是一個非常簡單的工程。它使用微服務方法，並依賴 Nomad、Kubernetes 和 Docker 等工具作為執行引擎。對於到 AWS 和 Kubernetes 的部署，它提供了一個很好的部署教程，但是，一旦進行中的 Helm Charts 完成，它就可以得到改進。

Screwdriver 還將 YAML 用於其管道描述，並包含許多合理的默認設定，因此，每個管道的樣板配置都比較少。該配置描述了一個高級工作流，作業之間可以有複雜的依賴關係。例如，可以保證一個作業在另一個作業之後或之前運行。作業可以並行運行，然後進行連接。你還可以使用邏輯操作符來運行作業，例如，如果作業的任何依賴項成功，或者只有所有依賴項都成功。更便利的是，你可以指定從 pull 請求觸發的特定作業。此外，當這種情況發生時，從屬作業不會運行，這使你可以很容易地隔離管道，以確定工件何時應該投入生產，何時仍然需要進行評審。

本文只是對這些 CI/CD 工具的簡要描述——它們都有更多很酷的特性和區別，你可以繼續研究它們。它們都是開源的，可以免費使用，你可以部署它們，看看哪個最適合你的需求。

英文原文

https://opensource.com/article/18/12/cicd-tools-sysadmins

點一下好看試試微信的新功能？