持續集成、持續交付和持續部署(CI/CD)在開發者社區已存在了多年。一些企業設有運維部門，但許多企業沒有。對於大多數企業而言，它們的運維團隊要像開發團隊那樣熟悉CI/CD工具和實踐。本文介紹了幾款一流的開源持續集成、持續交付和持續部署工具。
持續集成、持續交付和持續部署(CI/CD)在開發者社區已存在了多年。一些企業設有運維部門，但許多企業沒有。對於大多數企業而言，它們的運維團隊要像開發團隊那樣熟悉CI/CD工具和實踐。
CI/CD實踐同樣適用於基礎架構和第三方應用程序以及內部開發的應用程序。此外，有許多不同的工具，但都使用類似的模式。可能最重要的是，引導貴公司採用這種新的實踐將使你在公司內有很高的威信，你會成爲別人跟隨的領路人。
多年來，一些組織一直對基礎架構採用CI/CD實踐，使用Ansible、Chef或Puppet等工具。Test Kitchen等其他工具可以在最終託管應用程序的基礎架構上執行測試。事實上，那些測試甚至可以將應用程序部署到類似生產環境的環境中，針對更高級配置的生產負載執行應用程序級測試。然而，僅僅能夠測試基礎架構就很了不起。
與一些原始的配置管理工具相比，Terraform還可以使用Test Kitchen測試更短暫更冪等的基礎架構配置。加上Linux容器和Kubernetes，你現在可以使用類似生產環境的規範和資源來測試完整的基礎架構和應用程序部署，這些規範和資源在數小時內而不是數月或數年內創建和停用。一切資源在再次部署和測試之前清除乾淨。
然而，你還可以專注於對網絡配置或數據庫數據定義語言(DDL)文件進行版本控制，開始在其上面運行小型CI/CD管道。也許它只是檢查語法、語義或一些最佳實踐。實際上，大多數開發管道開始就是這樣。一旦你搭好了腳手架，就更容易在上面構建。一旦做好準備，你將開始爲管道尋找各種用例(use case)。
比如說，我經常在公司內部編寫業務通訊，使用MJML在版本控制中維護。我需要能託管一個Web版本，有些人喜歡能夠獲得PDF，於是我構建了一條管道。現在當我創建新的業務通訊時，將它提交、進行GitLab中的合併請求。這自動創建一個index.html，附有指向業務通訊HTML版和PDF版的鏈接。HTML和PDF文件也在管道中創建。除非有人來查看這些內容，否則這些都不發佈。然後，GitLab Pages發佈該網站，我可以下載HTML作爲業務通訊來發送。將來，我會在合併請求合併時或特殊的審批步驟後自動發送業務通訊。這看起來很簡單，但爲我節省了很多時間。這正是這些工具的精髓：它們可以爲你節省時間。
關鍵是創建抽象工作的工具，以便它們幾乎沒有變化即可應用於多個問題。我還應該指出，我創建的東西幾乎不需要編寫代碼，只需要幾個簡單的HTML模板、循環處理HTML文件的某個節點，以及往索引頁面填充所有HTML頁面和PDF的另一個節點。
其中一些可能看起來有點複雜，但大部分來自我所使用的不同工具的教程。而許多開發人員樂意在這些類型的工作上與你合作，因爲他們可能在完成後也覺得很有用。本文所附的鏈接指向我們計劃爲DevOps KC開辦的業務通訊，創建網站的所有代碼都來自我在搞內部業務通訊時所做的工作。
下面介紹的許多工具都能提供這種類型的交互，但一些提供的模式略有不同。這個領域的新興模式是用YAML之類的標記性語言對管道進行聲明性描述，每個階段是短暫冪等的。許多這些系統還通過在管道的不同階段創建有向無環圖(DAG)來確保正確的順序。
這些階段通常在Linux容器中運行，可以在容器中執行任何操作。某些工具(如Spinnaker)僅關注部署組件，提供了其他工具通常不包含的運維功能。Jenkins通常以XML格式來保存管道，大多數交互在GUI中進行，但最近的實現使用了採用Groovy的特定領域語言(DSL)。此外，Jenkins作業通常在已安裝特殊Java代理的節點上執行，由多個插件和預安裝組件組成。
Jenkins在其工具中引入了管道，但用起來有點困難，有幾個地方要注意。最近，Jenkins的開發者決定將社區引向幾個不同的計劃，這些計劃有望爲這個項目注入新活力，從而真正將CI/CD帶給大衆。我認爲最值得關注的計劃是創建可以將Kubernetes集羣變成Jenkins CI/CD平臺的雲原生Jenkins。
你進一步瞭解了這些工具並開始將這些實踐帶入貴公司或運維部門後，很快會有人亦步亦趨。你將提高自己和其他人的生產力。不妨更深入一點介紹這些工具。我們將簡要介紹每款工具，並附有提供更多信息的鏈接。
1.GitLab CI
項目頁面：https://about.gitlab.com/product/continuous-integration/
源代碼：https://gitlab.com/gitlab-org/gitlab-ce/
許可證：MIT
GitLab是CI/CD領域的新成員，但它已經成爲弗雷斯特研究公司持續集成工具Wave報告的佼佼者，這在競爭如此激烈的領域實屬不易。什麼讓GitLab CI如此出色?它使用YAML文件來描述整條管道。它還有一項名爲Auto DevOps的功能，讓較簡單的項目可以自動構建管道，並有內置的多個測試。
除了CI功能外，GitLab還提供許多補充功能，比如運維和監控，Prometheus會與你的應用程序一起自動部署;使用GitLab Issues、Epics和Milestones，實現項目組合和項目管理;安全檢查內置於管道中，結果作爲多個項目的合併值來提供;以及能夠使用WebIDE直接在GitLab中編輯代碼，甚至可以提供管道的預覽或執行部分以獲得更快的反饋。
2.GoCD
源代碼：https://github.com/gocd/gocd
許可證：Apache 2.0
GoCD來自Thoughtworks的奇思妙想，這足以證明其功能和效率。對我而言，GoCD與其他工具的區別主要在於其價值流圖(VSM，https://www.gocd.org/getting-started/part-3/#value_stream_map)功能。實際上，管道可以串聯起來，一條管道爲下一條管道提供“素材”。這使得部署過程中擁有不同職責的不同團隊加強了獨立性。將這種系統引入到打算讓這些團隊保持獨立的舊企業時，這項功能可能很有用――但讓每個人使用同樣的工具便於以後找到VSM中的瓶頸，並重新組織團隊或努力提高效率。
讓公司的每個產品都有VSM大有助益;GoCD允許在版本控制中以JSON或YAML來描述，並直觀地顯示所有數據，這使得該工具對於試圖更好地瞭解自身的企業來說更有價值。先安裝GoCD，僅使用手動批准關卡來描繪你的流程。然後讓每個團隊使用手動批准，以便你可以開始收集哪裏存在瓶頸方面的數據。
3.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圖表統統部署到Kubernetes會容易得多。那些圖表尚未部署所有內容，但我確信將來會變得更完善。如果你不想應對麻煩，還可以使用企業版。
然而，如果你在開發開源代碼，可以免費使用Travis CI的SaaS版。這是出色團隊提供的出色服務!這減輕了大量開銷，讓你可以使用很常見的平臺來開發開源代碼，沒必要運行任何東西。
4.Jenkins
項目頁面：https://jenkins.io/
源代碼：https://github.com/jenkinsci/jenkins
許可證：MIT
Jenkins是CI/CD界最正宗、最值得尊敬的事實上的標準。建議你讀一下Jenkin的開發者兼CloudBees首席技術官Kohsuke撰寫的《Jenkins：Shifting Gears》(https://jenkins.io/blog/2018/08/31/shifting-gears/)。它總結了過去十年我對Jenkins及社區的種種感受。他描述了多年來需要的創新，我很高興CloudBees在這場轉型中身先士卒。Jenkins對大多數非開發人員來說難度有點大，向來是管理員的一種負擔。然而，這些方面是他們旨在解決的。
Jenkins配置即代碼(JCasC)應該有助於解決困擾管理員多年的複雜配置問題。這便於通過YAML文件對Jenkins主機進行零接觸配置，類似其他CI/CD系統。Jenkins Evergreen旨在基於不同的用例提供預定義的Jenkins配置，從而使這個過程來得更容易。與普通的Jenkins發行版相比，這些發行版應該更易於維護和升級。
Jenkins 2引入了原生管道功能，有兩種類型的管道。你做一些簡單的事情時，兩種管道用起來都不如YAML那麼容易，但它們對於完成更復雜的任務相當好。
Jenkins X堪稱Jenkins的全面轉型，很可能是雲原生Jenkins的實現(或至少是大多數用戶使用雲原生Jenkins時看到的東西)。它將拿來JCasC和Evergreen，直接在Kubernetes上使用、用其所長。對Jenkins來說，眼下是激動人心的時刻，我期待着它繼續創新、不斷領導這個領域。
5.Concourse CI
項目頁面：https://concourse-ci.org/
源代碼：https://github.com/concourse/concourse
許可證：Apache 2.0
我通過Pivotal Labs的人員首次接觸了Concourse，那時它還是早期測試版，當時沒有很多同類的工具。該系統由微服務組成，每個作業都在容器內運行。它最有用的其他工具所沒有的功能之一是，能夠從本地系統運行作業。這意味着你可以在本地開發(假設你連接到Concourse服務器)並運行你構建的代碼，就像在真實的構建管道中運行一樣。此外，你可以從本地系統重新運行失效的構建版本，並注入特定的更改來測試修復程序。
Concourse還有一個簡單的擴展系統，依賴資源的基本概念。大致上來說，你希望提供給管道的每項新功能都可以在Docker鏡像中實現，並作爲新的資源類型包含在配置中。這使得所有功能都封裝在一個可以獨立升級和修改的單個不可變工件中，破壞性變更未必同時 破壞所有構建版本。
6.Spinnaker
項目頁面：https://www.spinnaker.io/
源代碼：https://github.com/spinnaker/spinnaker
許可證：Apache 2.0
Spinnaker來自Netflix，關注持續部署多過關注持續集成。它可以與其他工具集成，包括Travis和Jenkins，以啓動測試和部署管道。它還與Prometheus和Datadog等監控工具集成，基於這些系統提供的度量指標做出部署方面的決策。比如說，金絲雀部署使用judge概念和收集的度量指標來確定最新的金絲雀部署是否導致相關度量指標出現任何降級、應該回滾，或確定部署是否可以繼續。
與部署有關的幾項額外的獨特功能涵蓋了討論持續部署時常常被忽視的一個方面，這個方面看似對立，但對成功而言至關重要：Spinnaker有助於使持續部署不那麼持續。它將阻止一個階段在某些時間運行，防止部署在應用程序生命週期的關鍵時間內出現。它還可以執行手動審批，確保公司業務從變更獲得最大的好處後才發佈。實際上，持續集成和持續部署的全部意義在於，業務需求一有變化，準備好儘快部署變更。
7.Screwdriver
源代碼：https://github.com/screwdriver-cd/screwdriver
許可證：BSD
Screwdriver是一款異常簡單的工具。它使用微服務方法，依賴Nomad、Kubernetes和Docker等工具充當其執行引擎。有一篇很好的部署教程(https://docs.screwdriver.cd/cluster-management/kubernetes)介紹如何部署到AWS和Kubernetes，但是一旦開發中的Helm圖表(https://github.com/screwdriver-cd/screwdriver-chart)完成，Screwdriver有望得到改進。
Screwdriver還使用YAML來描述管理，包含許多合理的默認值，因此每個管道的樣板配置較少。配置描述了作業之間可能有複雜依賴項的高級工作流。比如說，可以保證作業在另一個作業之後或之前運行。作業可以並行運行，然後結合。比如說，如果任何依賴項成功或只有所有依賴項成功，你還可以使用邏輯運算符來運行作業。更棒的是，你可以指定從合併請求觸發的某些作業。此外，發生這種情況時，依賴作業不會運行，這樣工件進入到生產環境、仍需要進行審查時可以輕鬆隔離管道。
本文簡要描述了這些CI/CD工具，每個工具有更酷的功能和差異化優勢，應研究一下。它們都是開源的，可以免費使用，所以部署一下，看看哪個最符合你的要求。