使用開源工具構建 DevOps Pipeline 的初學者指南
DevOps 生態需要考慮各種需求，例如持續整合方案、源控制管理、自動化構建、伺服器選擇、測試覆蓋率等。本文通過 5 個關鍵步驟，向 DevOps 初學者介紹如何通過流行的開源工具來解決這些需求。
DevOps 在修復緩慢、孤立或其他功能失調方面已成為軟體開發過程的首選方案。如果剛接觸 DevOps 並且不確定從哪裡開始，可以參考本文 DevOps Pipeline 的內容，以及建立一個 Pipeline 的五個步驟。
DevOps 之旅
我曾經在花旗集團的雲團隊工作，開發基礎架構即服務（IaaS）Web 應用程式來管理花旗的雲基礎架構，但總想找到方法來提高開發流程效率，併為開發團隊帶來積極的文化變革。我在 Greg Lavender 推薦的一本書中找到了答案，他是花旗雲架構和基礎設施工程的首席技術官，書名叫 The Phoenix Project ，它像一本小說一樣闡釋了 DevOps 的原則。
下面的表格顯示了不同公司部署到釋出環境的頻率：
Amazon、Google 和 Netflix 的頻率是如何做到的？這是因為這些公司已經找到了製作一個近乎完美的 DevOps Pipeline 的方法。
花旗在實施 DevOps 之前，情況並非如此良好。那時候，團隊有不同的階段性環境，但是開發伺服器的部署是非常手動的。所有開發人員只能訪問基於 IBM WebSphere Application Server Community Edition 的一個開發伺服器。問題是，當試圖為多個使用者同時進行部署時，伺服器就會崩潰，因此開發人員不得不在即將進行部署時讓對方知道，這點讓人非常痛苦。此外，還存在程式碼測試覆蓋率低、手動部署過程繁瑣，以及無法繫結已定義的任務或使用者故事來跟蹤程式碼部署的問題。
我意識到必須要做一些改變，並找到了志同道合的同事。我們決定合作構建一個初始 DevOps 管道 - 他在 Jenkins 工作期間設定了虛擬機器和 Tomcat 應用伺服器，與 Atlassian Jira 和 BitBucket 整合等。之後，該專案取得了巨大成功：幾乎完全自動化了開發流程，在開發伺服器上實現了近 100％的正常執行時間，可以跟蹤和改進程式碼測試覆蓋率，Git 分支可以與部署和 Jira 任務相關聯。並且，用於構建 DevOps 管道的大多數工具都是開源的。我現在意識到，DevOps 管道還存在不足，因為沒有利用類似 Jenkins 檔案或 Ansible 這樣的高階配置。然而，這個簡單的過程運作良好，可能是由於 帕累託 原則（也稱為 80/20 規則）。
DevOps 和 CI/CD Pipeline 簡要介紹
如果隨便問幾個人，“什麼是 DevOps？”，可能會得到幾個不同的答案。與敏捷開發一樣，DevOps 已經發展到包含許多不同學科，但是大多數人會認可：DevOps 是一個軟體開發實踐或者軟體開發生命週期（SDLC），核心原則是一種文化變革，開發人員和非開發人員都在一個原本是手動操作、現在是自動化的環境中工作，每個人都做最擅長的事情，每個時期的部署數量都在增加，吞吐量也在增加，靈活性則逐漸提高。
雖然合適的軟體工具並不是實現 DevOps 環境所需的唯一辦法，但有些工具是必需的。關鍵是持續整合和持續部署（CI/CD）。Pipeline 構建了一個環境，具有不同的階段（例如，DEV，INT，TST，QA，UAT，STG，PROD），手工部分被自動化，開發人員可以實現高質量、高靈活性的程式碼，並允許大量部署。
本文介紹了使用開源工具建立 DevOps Pipeline 的五步方法，如下圖所示：
第 1 步：CI/CD 框架
第一件事是找一款 CI/CD 工具。Jenkins 是一個基於 Java 開源的、基於 MIT 許可證的 CI/CD 工具，已成為 DevOps 的標準。
Jenkins 是什麼？想象一種神奇的通用遙控器，Jenkins 可以與許多不同的服務和工具互動協調。類似 Jenkins 這樣的 CI/CD 工具本身沒多大用，但隨著插入不同的工具和服務，將變得越來越強大。
Jenkins 只是眾多開源 CI/CD 工具中的一種，可以利用它來構建 DevOps Pipeline。
以下是使用 CI/CD 工具的 DevOps 流程：
現在本地主機中運行了 CI/CD 工具，可以開始 DevOps 之旅的下一步。
第 2 步：源控制管理
驗證 CI/CD 工具是如何運作最佳（也可能是最簡單）方法是與源控制管理（SCM）工具整合。為什麼需要原始碼管理？假設正在開發一個應用程式，無論何時要構建應用程式，都需要程式設計，無論是 Java、Python、C ++、Go、Ruby、JavaScript 還是其他任何一種程式語言，所編寫的程式設計程式碼稱為原始碼。
一開始，尤其是獨自工作時，開發者將所有內容放在本地目錄可能是可以的。但是，當專案變得更大並且需要邀請其他人協作時，需要一種方法來避免合併衝突，同時有效共享程式碼修改，還需要一種方法來恢復以前的版本，備份、複製和貼上就顯得比較落伍，開發者可能需要更好的東西。
這就是 SCM 幾乎成為必需品的原因，SCM 工具通過將程式碼儲存在儲存庫中，對程式碼進行版本控制，在專案成員之間進行協調來提供幫助。
實際上，有很多 SCM 工具，Git 是一個標準。強烈建議使用 Git，但如果願意，還有其他開源可選：
以下是新增 SCM 後 DevOps 管道的樣子：
CI/CD 工具可以自動執行原始碼遷入和遷出，執行跨成員協作任務。但是，如何將其變成一個有效的應用程式，以便數十億人可以使用和欣賞呢？
第 3 步：自動化構建工具
開發者可以檢視程式碼並將更改提交到原始碼管理，然後邀請朋友進行原始碼管理開發和協作。如果到目前還沒有構建應用程式，要使其成為一款 Web 應用程式，必須進行編譯並放入可部署的包或作為可執行檔案執行。（請注意，像 JavaScript 或 PHP 這樣的解釋型語言不需要編譯）
現在來看看自動化構建工具。無論決定使用哪種構建工具，都有一個共同目標：將原始碼構建為某種所需格式，並自動執行任務來清理、編譯、測試並部署到特定位置。構建工具將根據程式語言而有所不同，這裡有一些常見的開源選項可以考慮：
現在，可以將自動化構建工具的配置檔案放入原始碼管理，然後讓 CI/CD 工具構建它：
一切都很好，對吧？但是，在哪裡進行部署呢？
第 4 步：Web 應用程式伺服器
到目前為止，開發者有一個可執行或可部署打包檔案。對於任何真正有用的應用程式，必須提供某種服務或介面，但還需要一個容器來託管應用程式。
對於 web 應用程式，web 伺服器就是這類容器。應用程式伺服器提供了這樣一個環境，可以檢測可部署包內的程式設計邏輯、公開介面，通過 socket 向外部提供 web 服務。HTTP 伺服器以及其他一些環境（如虛擬機器）可以用來安裝應用程式伺服器。
有許多可用的開源 web 應用程式伺服器：
現在，DevOps Pipeline 基本可以使用：
雖然可以就此進行下一步整合，但程式碼質量對於應用程式開發人員來說是一件很重要的事情。
第 5 步：程式碼測試覆蓋率
另一個繁瑣的要求可能是實現程式碼測試，開發人員需要儘早捕獲應用程式中的任何錯誤，提高程式碼質量以確保終端使用者滿意。幸運的是，有許多開源工具可用於測試程式碼並提出改進其質量的方法。更好的訊息是，大多數 CI/CD 工具可以插入這些工具並將這個過程自動化。
程式碼測試分為兩部分：協助編寫、執行測試的程式碼測試框架，以及有助於提高程式碼質量的程式碼質量建議工具。
程式碼測試框架：
程式碼質量建議工具：
請注意，上面提到的大多數工具和框架都是針對 Java、Python 和 JavaScript 編寫的，因為 C ++ 和 C# 是專有程式語言（儘管 GCC 是開源的）。
現在已經實現了程式碼測試覆蓋工具，DevOps Pipeline 應該類似於本教程開頭所示的 DevOps Pipeline 圖。
可選的步驟
容器
如上所述，可以在虛擬機器或伺服器上託管應用程式伺服器，但容器是一種流行的解決方案。
什麼是容器 ？簡短的解釋就是 VM 自身需要佔用作業系統的巨大空間，這會佔用應用程式的大小，而容器只需要一些庫和配置就可以執行應用程式。顯然 VM 仍有重要的用途，但容器是託管應用程式（包括應用程式伺服器）的輕量級解決方案。
雖然有多種容器可選擇，但 Docker 和 Kubernetes 是最受歡迎的：
中介軟體自動化工具
DevOps Pipeline 主要側重於協作構建和部署應用程式，還可以使用 DevOps 工具執行許多其他操作。其中之一是利用 Infrastructure as Code（IaC）工具，也稱為中介軟體自動化工具。這些工具有助於自動化中介軟體軟體的安裝、管理和其他任務。例如，自動化工具可以通過正確的配置提取應用程式（如 Web 應用程式伺服器、資料庫和監視工具），並將它們部署到應用程式伺服器。
以下是幾個可以考慮的開源中介軟體自動化工具：
原文連結： A beginner’s guide to building DevOps pipelines with open source tools