了解自動化，使用 Git 儲存庫以及引數化 Jenkins 管道。
本文涵蓋了三個關鍵主題：自動化 CI/CD 設定、使用 Git 儲存庫處理常見的 CI/CD 工件、引數化 Jenkins 管道。
首先，我們定義一些術語。CI/CD 是允許團隊快速自動化測試、打包、部署其應用程式的實踐。它通常通過利用名為 Jenkins 的伺服器來實現，該伺服器充當 CI/CD 協調器。Jenkins 偵聽特定輸入（通常是程式碼簽入後的 Git 掛鉤），並在觸發時啟動一個管道。
管道 由開發和/或運營團隊編寫的程式碼組成，這些程式碼指導 Jenkins 在 CI/CD 過程中採取哪些操作。這個流水線通常類似於“構建我的程式碼，然後測試我的程式碼，如果這些測試通過，則把我的應用程式部署到下一個最高環境（通常是開發、測試或生產環境）”。組織通常具有更複雜的管道，並入了諸如工件儲存庫和程式碼分析器之類的工具，這裡提供了一個高階範例。
現在我們了解了關鍵術語，讓我們深入研究一些最佳實踐。
要在 PaaS 上執行 CI/CD，需要在叢集上設定適當的基礎設施。在這個例子中，我將使用 OpenShift。
“Hello, World” 的實現很容易實現。簡單地執行 oc new-app jenkins-<persistent/ephemeral>，然後，你就有了一個已經就緒的執行中的 Jenkins 伺服器了。然而，在企業中的使用要複雜得多。除了 Jenkins 伺服器之外，管理員通常還需要部署程式碼分析工具（如 SonarQube）和工件庫（如 Nexus）。然後，它們必須建立管道來執行 CI/CD 和 Jenkins 從伺服器，以減少主伺服器的負載。這些實體中的大多數都由 OpenShift 資源支援，需要建立這些資源來部署所需的 CI/CD 基礎設施。
最後，部署 CI/CD 元件所需要的手動步驟可能是需要重複進行的，而且你可能不想成為執行那些重複步驟的人。為了確保結果能夠像以前一樣快速、無錯誤和準確地產生，應該在建立基礎設施的方式中結合自動化方法。這可以是一個 Ansible 劇本、一個 Bash 指令碼，或者任何您希望自動化 CI/CD 基礎設施部署的其它方式。我已經使用 Ansible 和 OpenShift-Applier 角色來自動化我的實現。您可能會發現這些工具很有價值，或者您可能會發現其他一些對您和組織更有效的工具。無論哪種方式，您都將發現自動化顯著地減少了重新建立 CI/CD 元件所需的工作量。
除了一般的“自動化”之外，我想單獨介紹一下 Jenkins 主伺服器，並討論管理員如何利用 OpenShift 來自動化設定 Jenkins。來自 Red Hat Container Catalog 的 Jenkins 映象已經安裝了 OpenShift-Sync plugin。在 該視訊 中，我們將討論如何使用這個外掛來建立 Jenkins 管道和從裝置。
要建立 Jenkins 管道，請建立一個類似於下面的 OpenShift BuildConfig：
apiVersion: v1kind: BuildConfig...spec: source: git: ref: master uri: <repository-uri> ... strategy: jenkinsPipelineStrategy: jenkinsfilePath: Jenkinsfile type: JenkinsPipelineOpenShift-Sync 外掛將注意到已經建立了帶有 jenkinsPipelineStrategy 策略的 BuildConfig，並將其轉換為 Jenkins 管道，從 Git 源指定的 Jenkinsfile 中提取。也可以使用內聯 Jenkinsfile，而不是從 Git 儲存庫中提取。有關更多資訊，請參閱文件。
要建立 Jenkins 從站，請建立一個 OpenShift ImageStream，它從以下定義開始：
apiVersion: v1kind: ImageStreammetadata: annotations: slave-label: jenkins-slave labels: role: jenkins-slave...注意在這個 ImageStream 中定義的後設資料。OpenShift-Sync 外掛將把帶有標籤 role: jenkins-slave 的任何 ImageStream 轉換為 Jenkins 從站。Jenkins 從站將以 slave-label 注釋中的值命名。
ImageStreams 對於簡單的 Jenkins 從屬設定工作得很好，但是一些團隊會發現有必要設定一些細節詳情，比如資源限制、準備就緒和活動性探測，以及範例上限。這就是 ConfigMap 發揮作用的地方：
apiVersion: v1kind: ConfigMapmetadata: labels: role: jenkins-slave...data: template1: |- <Kubernetes pod template>注意，仍然需要角色：jenkins-slave 標籤來將 ConfigMap 轉換為 Jenkins 從站。Kubernetes pod 模板由一長段 XML 組成，它將根據組織的喜好設定每個細節。要檢視此 XML，以及有關將 ImageStreams 和 ConfigMaps 轉換為 Jenkins 從站的更多資訊，請參閱文件。
請注意上面所示的三個範例，其中沒有一個操作需要管理員對 Jenkins 控制台進行手動更改。通過使用 OpenShift 資源，可以簡單的自動化方式設定 Jenkins。
第二個最佳實踐是維護一個公共 CI/CD 工件的 Git 儲存庫。主要思想是防止團隊重新發明輪子。假設您的團隊需要執行到 OpenShift 環境的藍/綠部署，作為管道 CD 階段的一部分。負責編寫管道的團隊成員可能不是 OpenShift 專家，也不可能具有從頭開始編寫此功能的能力。幸運的是，有人已經編寫了一個將此功能合併到一個公共 CI/CD 儲存庫中的函數，因此您的團隊可以使用該函數而不是花時間編寫一個函數。
為了更進一步，您的組織可能決定維護整個管道。您可能會發現團隊正在編寫具有相似功能的管道。對於那些團隊來說，使用來自公共儲存庫的引數化管道要比從頭開始編寫自己的管道更有效。
正如我在前一節中提到的，第三個也是最後一個最佳實踐是引數化您的 CI/CD 管道。引數化將防止過多的管道，使您的 CI/CD 系統更容易維護。假設我有多個區域可以部署應用程式。如果沒有引數化，我需要為每個區域設定單獨的管道。
要引數化一個作為 OpenShift 構建設定編寫的管道，請將 env 節新增到設定：
...spec: ... strategy: jenkinsPipelineStrategy: env: - name: REGION value: US-West jenkinsfilePath: Jenkinsfile type: JenkinsPipeline使用此設定，我可以傳遞 REGION 引數給管道以將我的應用程式部署到指定區域。
這有一個視訊提供了一個更實質性的情況，其中引數化是必須的。一些組織決定把他們的 CI/CD 管道分割成單獨的 CI 和 CD 管道，通常是因為在部署之前有一些審批過程。假設我有四個映象和三個不同的環境要部署。如果沒有引數化，我需要 12 個 CD 管道來允許所有部署可能性。這會很快失去控制。為了使 CD 流水線的維護更容易，組織會發現將映象和環境引數化以便允許一個流水線執行多個流水線的工作會更好。
企業級的 CI/CD 往往比許多組織預期的更加複雜。幸運的是，對於 Jenkins，有很多方法可以無縫地提供設定的自動化。維護一個公共 CI/CD 工件的 Git 儲存庫也會減輕工作量，因為團隊可以從維護的依賴項中提取而不是從頭開始編寫自己的依賴項。最後，CI/CD 管道的引數化將減少必須維護的管道的數量。
如果您找到了其他不可或缺的做法，請在評論中分享。