持續集成、持續交付和持續部署（CI/CD）在開發社區中已經存在多年。有些組織已經有相應的運營工具，但許多沒有。對於大多數組織來說，運營團隊必須像開發團隊一樣熟悉CI/CD工具和實踐。
CI/CD實踐對於基礎設施、第三方應用程序和內部開發的應用程序同樣適用。雖然有許多不同的工具可以實踐CI/CD，但這些工具都使用類似的模型。最重要的也許是，引導公司採取這種新的做法會讓你在公司裏處於一個強有力的地位，成爲別人前進的燈塔。
有些團隊多年來一直在基礎設施上使用CI/CD實踐，藉助類似Ansible、Chef或Puppet這樣的工具。其他工具，如Test Kitchen，允許在最終將託管應用程序的基礎設施上執行測試。事實上，這些測試甚至可以將應用程序部署到類似於生產的環境中，使用生產負載在更高的配置上執行應用程序級測試。然而，能夠單獨測試基礎設施就是一個巨大的成就。Terraform還可以使用Test Kitchen實現比一些原始配置管理工具更加短暫的冪等基礎設施配置。再加上Linux容器和Kubernetes，你現在就可以使用與生產環境類似的規範和資源測試完整的基礎設施和應用程序部署，這些資源的使用和釋放只需幾個小時，而不是幾個月或幾年。在重新部署和測試之前，所有內容都會被刪除。
但是，你還可以致力於將網絡配置或數據庫數據定義語言（DDL）文件放到版本控制系統中，並開始在這些文件上運行小型的CI/CD管道。也許只是檢查語法、語義或一些最佳實踐。實際上，大多數開發管道都是這樣開始的。一旦你搭好腳手架，它就比較容易構建了。一旦開始，你就會開始找到各種各樣的管道用例。
例如，我經常在公司內編寫時事通訊，並使用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真正帶給大衆的項目。我認爲最有趣的是創建一個原生雲Jenkins，它可以將一個Kubernetes集羣轉變爲Jenkins CI/CD平臺。
當你進一步瞭解這些工具並開始將這些實踐引入公司或運營部門時，你很快就會有追隨者。你會提高自己和別人的工作效率。我們都有多年的積壓工作要做——如果你能給他們足夠的時間來處理這些積壓工作，你的同事會多麼喜歡呢？當你的應用程序可靠性的不斷提高時，在下一次薪資談判或面試時你就有了話語權。
讓我們更深入地研究下這些工具。我們將對每一個工具進行簡要地介紹，並分享可以讓你瞭解更多信息的鏈接。
GitLab CI
GitLab是CI/CD領域的一個新手玩家，但它已經在Forrester Wave持續集成工具中佔據了領先地位。在這樣一個競爭對手衆多而水平又很高的領域，這是一項巨大的成就。是什麼讓GitLab CI如此了不起？
- 它使用YAML文件來描述整個管道。
- 它還有一個功能叫Auto DevOps，使比較簡單的項目可以自動構建內置了若干測試的管道。
- 使用Herokuish構建包來確定語言以及如何構建應用程序。有些語言還可以管理數據庫，對於構建新的應用程序並在開發過程一開始就將其部署到生產環境中，這是一個很重要的功能。
- 提供到Kubernetes集羣的原生集成，並使用多種部署方法的一種（如基於百分比的部署和藍綠部署）將應用程序自動部署到Kubernetes集羣中。
除了CI功能之外，GitLab還提供了許多補充功能，比如自動把Prometheus 和你的應用程序一起部署，實現運行監控；使用GitLab問題（Issues）、史詩（Epics）和里程碑（Milestones）進行項目組合和項目管理；管道內置了安全檢查，提供跨多個項目的聚合結果；使用WebIDE在GitLab中編輯代碼的能力，它甚至可以提供預覽或執行管道的一部分，以獲得更快的反饋。
GoCD
GoCD出自Thoughtworks的大師之手，這足以證明它的能力和效率。對我來說，GoCD與其他工具的主要區別在於它的價值流圖（VSM）特性。事實上，管道可以與管道連接在一起，爲下一條管道提供“材料”。這使得部署過程中具有不同職責的團隊更加獨立。在希望保持團隊隔離性的舊組織中引入這種類型的系統時，這可能是一個有用的特性，但是，讓每個人都使用相同的工具，以後會更容易發現VSM中的瓶頸，那樣就可以重新組織團隊或工作以提高效率。
爲公司的每個產品都配備VSM是非常有價值的；GoCD允許在版本控制系統中以JSON或YAML的形式對其進行描述，並以可視化的方式顯示所有有關等待時間的數據，這使得這個工具對於想更好地理解自己的組織的人更有價值。從安裝GoCD開始，只需要藉助手動審批門（manual approval gates）就可以完成流程映射。然後讓每個團隊使用手動審批，這樣你就可以開始在可能存在瓶頸的地方收集數據。
Travis CI
Travis CI是我第一次使用軟件即服務（SaaS） CI系統，它非常棒。管道以YAML的形式存儲在源代碼中，可以與GitHub等工具無縫集成。我不記得上一次由於Travis CI或集成而導致管道失敗是什麼時候了——Travis CI的正常運行時間非常長。它不僅可以作爲SaaS使用，而且還有一個可以託管的版本，我還沒有運行這個版本，因爲它有很多組件，安裝起來似乎有點困難。
我覺得，用Travis CI提供的Helm Charts將它部署到Kubernetes會容易得多。這些Chart並沒有把所有內容都部署，但我相信，它未來可以部署更多內容。如果你不想自己處理這些麻煩，還有一個企業版本。
但是，如果你正在開發開源代碼，那麼就可以免費使用Travis CI的SaaS版本。這是一個很棒的團隊提供的很棒的服務！這會大幅降低開銷，並且允許你使用一個相當通用的平臺來開發開源代碼，而無需運行任何東西。
Jenkins
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
我第一次聽說Concourse是通過Pivotal Labs的同事介紹的，那是一個早期的Beta版本——當時還沒有多少類似的工具。該系統由微服務組成，每個作業在一個容器中運行。它獨家提供的一個最有用的特性是：從本地系統（可進行本地修改）運行一項作業的能力。這意味着你可以在本地進行開發（假設你已經連接到Concourse服務器），並像在實際構建管道中那樣運行構建。此外，你還可以從本地系統重新運行失敗的構建，並注入特定的更改來測試修復程序。
Concourse還有一個簡單的擴展系統，它以資源這個基本概念爲基礎。基本上，你希望向管道提供的每個新特性都可以在Docker鏡像中實現，並作爲新的資源類型包含在配置中。這使得所有的功能都封裝在一個單一的不可變工件中，可以獨立地升級和修改，而破壞更改並不一定要同時破壞所有的構建。
Spinnaker
Spinnaker來自Netflix，它更側重於持續部署而不是持續集成。它可以與其他工具集成，包括Travis和Jenkins，以啓動測試和部署管道。它還集成了Prometheus和Datadog等監控工具，根據這些系統提供的指標可以進行部署決策。例如，金絲雀部署使用判斷的概念和收集的指標來確定最新的金絲雀部署是否導致了相關指標的下降，是否應該回滾，或者是否可以繼續部署。
與部署相關的一些額外的、獨特的特性涵蓋了我們在討論持續部署時經常忽略的一個領域，甚至可能看起來正相反的領域，但對於成功來說卻至關重要：Spinnaker可以使持續部署不那麼持續。它可以阻止某個階段在特定時間運行，從而防止部署在應用程序生命週期的關鍵時刻發生。它還可以強制手動審批，以確保在業務可以從更改中獲得最大收益的時候發佈。事實上，持續集成和持續部署的全部要點是準備好在業務需要更改時儘快部署變更。
Screwdriver
Screwdriver是一個非常簡單的工程。它使用微服務方法，並依賴Nomad、Kubernetes和Docker等工具作爲執行引擎。對於到AWS和Kubernetes的部署，它提供了一個很好的部署教程，但是，一旦進行中的Helm Charts完成，它就可以得到改進。
Screwdriver還將YAML用於其管道描述，幷包含許多合理的默認設置，因此，每個管道的樣板配置都比較少。該配置描述了一個高級工作流，作業之間可以有複雜的依賴關係。例如，可以保證一個作業在另一個作業之後或之前運行。作業可以並行運行，然後進行連接。你還可以使用邏輯操作符來運行作業，例如，如果作業的任何依賴項成功，或者只有所有依賴項都成功。更便利的是，你可以指定從pull請求觸發的特定作業。此外，當這種情況發生時，從屬作業不會運行，這使你可以很容易地隔離管道，以確定工件何時應該投入生產，何時仍然需要進行評審。
本文只是對這些CI/CD工具的簡要描述——它們都有更多很酷的特性和區別，你可以繼續研究它們。它們都是開源的，可以免費使用，你可以部署它們，看看哪個最適合你的需求。
英語原文：