連續集成和Jenkins CI服務器的關鍵指南-IT業界-PHP中文網

持續集成 (CI) 和 Jenkins CI 服務器是現代軟件開發中不可或缺的工具，它們通過自動化重複性流程來幫助團隊發布更高質量的軟件並節省時間。
CI 強調測試自動化，使測試工程師能夠專注於探索性測試和邊緣情況，同時確保在開發人員提交後的幾分鐘內，特定分支上的每次提交的質量。
Jenkins CI 服務器是一個開源的 CI 工具，可以通過現有插件或創建新插件進行自定義。它支持通過在多台機器上分配任務來進行並行構建，並處理各種語言（包括 Python）項目的持續集成。
雖然 Jenkins 需要更多設置和維護，但其靈活性和可控性以及免費的開源特性使其成為優於其他 CI 服務器的強大選擇。它還可以很好地與各種版本控制系統集成，使其成為不同項目的通用工具。

Key Guidelines to Continuous Integration and Jenkins CI Server

本文最初發表在 TestProject——測試自動化博客上

下文將詳細介紹持續集成 (CI)，這是軟件開發中一項必不可少的實踐，以及 Jenkins，業界標準的開源持續集成工具。通過實施持續集成和 Jenkins CI 服務器，您將了解 Jenkins 部署如何幫助您的開發團隊發布更高質量的軟件並節省寶貴的時間。

想要了解更多關於 Jenkins 和持續集成的信息？請查看以下鏈接：

屏幕錄製：哪些持續集成工具支持 Bitbucket？
在 Jenkins 中準備和構建 PHP 項目
使用 Jenkins 進行持續集成
重新介紹 Jenkins：使用流水線的自動化測試
安裝和保護 Jenkins

現代軟件開發實踐要求盡快或經常在生產環境中部署功能完善的軟件。例如，敏捷方法直接強制執行此行為，方法是讓團隊以少量增量工作，並在每次沖刺後部署到生產環境（閱讀：敏捷項目的測試自動化策略）。

開發團隊花費數月時間開發軟件，然後將其傳遞給 QA、UAT 和所有生產線的情況已經不復存在了。如今，重點是擁有功能完善的軟件，並且永遠不允許危及軟件質量的情況發生，例如在發布週期結束時引入重要的軟件更改。這就是持續集成發揮作用的地方。

什麼是 CI？

CI 是一種實踐，它強制執行將經過測試的代碼頻繁集成到項目穩定分支的策略。我尤其要強調“經過測試的代碼”，因為這意味著在單獨分支上開發的功能也經過測試，因此被集成到穩定分支。

誰在做 CI？

通常，DevOps 工程師通常負責設置 CI 管道。如今，DevOps 工程師的角色與測試工程師非常相似，因為兩者都確保流程和軟件質量。我通常說 QA 和生產是與客戶最接近的交匯點。從這個意義上說，CI 為測試工程師提供了非常強大的工具，可以通過積極參與以下領域來提高整體流程和軟件質量：

測試自動化：幾年前，人們討論過手動測試與自動化測試。使用 CI，測試自動化變得不可或缺，這最終將節省大量寶貴的時間來專注於其他測試任務。還值得一提的是，手動測試和自動化測試不能相互排斥。
測試報告：對於 CI 中的測試報告，我們可以使用現有的報告解決方案或構建我們自己的報告模塊。在這兩種情況下，這都清楚地表明了我們的應用程序代碼在每次構建運行中的“健康狀況”。重要的是，所有開發團隊成員都可以訪問此信息，並且將不斷努力以提高代碼質量。
部署流程：測試工程師更多地參與應用程序的部署過程，這會提供有關所用測試自動化工具或框架的內部架構的附加信息。這些知識非常重要，尤其是在識別“隱藏”的應用程序問題時。

CI 的好處

CI 強調測試自動化，使測試工程師能夠專注於探索性測試、邊緣情況測試，甚至尋找新的測試方法。
特定分支上特定提交的質量在開發人員提交後的幾分鐘內即可顯現。
代碼在分支上經過測試後，集成到穩定分支非常謹慎（CI 流程應該運行此操作）。應用程序的部署一旦正確設置就會自動執行，不需要重複的命令。
從團隊的角度來看，所有這些好處都會成倍增加。

典型的 CI 場景

開發團隊擁有自己的源代碼版本控制存儲庫，其中包含項目（如今通常是 GitHub）。穩定分支（主分支）通常被認為是工作分支，很少直接在主分支上開發新功能。相反，開發人員創建他們自己的分支來開發新功能（功能 A 的分支 A）。當更改被推送到該特定分支上的存儲庫並且開發人員發出拉取請求時，應該針對該分支執行一些基本的測試集（冒煙測試）。從 CI 的角度來看，這通常意味著以下幾點：

Key Guidelines to Continuous Integration and Jenkins CI Server

當 CI 流程完成後，從測試工程師和開發人員的角度來看，有以下一些要求：

測試人員：再次在分支 A 上重新測試功能 A
開發人員：另一位開發人員進行同行代碼審查，以確保代碼質量足夠好
開發人員：手動將代碼合併到主分支並解決任何合併衝突（如果出現）。

冒煙測試為將進行代碼審查的開發人員以及需要在拉取請求分支上重新測試功能 A 的測試工程師節省了大量時間。如果拉取請求上的冒煙測試失敗，那麼負責功能A 的開發人員現在有責任修復冒煙測試功能並發出新的拉取請求（直到修復問題，有問題的代碼都不會合併到主分支）。

如果通過此操作，並且功能 A 的新代碼從 CI 的角度合併到主分支，則會發生以下情況：

Key Guidelines to Continuous Integration and Jenkins CI Server

這表明合併成功，冒煙測試功能仍然有效，現在測試工程師有責任再次在主分支上重新測試功能 A（以確保合併不會對功能 A 產生任何副作用）。當然，隨著時間的推移，增強測試自動化套件是一個好習慣，以便涵蓋大部分功能。

這在項目的後期迭代中變得越來越重要，因為測試工程師有更多任務（測試當前功能以及所有以前的功能）。這就是回歸測試派上用場的地方：從 CI 的角度來看，回歸測試的執行通常發生在測試工程師明確運行回歸測試時或使用調度程序時（例如：每晚執行回歸測試）。這是一個好習慣，可以自定義此作業，以便我們可以指定將針對哪個分支執行此作業（在這裡您可以閱讀更多關於為什麼以及何時執行回歸測試自動化的信息）。該過程如下所示：

Key Guidelines to Continuous Integration and Jenkins CI Server

Jenkins 工具簡介

Jenkins CI 服務器術語

作業：Jenkins 術語中最重要的“單元”是作業。作業是 Jenkins CI 服務器中的單個執行單元，必須有一定的結果（通過/失敗）。例如：作業可以是部署作業、冒煙測試作業、回歸測試作業等。作業由按順序執行的多個區域組成，這將在下一段中解釋：Jenkins 作業的結構。

插件：Jenkins 測試自動化的主要功能之一是能夠通過使用現有插件或創建自己的插件來對其進行自定義。 Jenkins 工具中的所有內容，從作業配置部分到 Jenkins 配置部分，實際上都是插件。由於 Jenkins 的社區規模龐大，因此已經存在各種 Jenkins 插件來滿足最苛刻的 CI 工作流任務的需求。這意味著，您很可能會遇到一個有用的插件，而不是創建自定義解決方案。

節點：在最簡單的設置中，Jenkins 實例將在一台機器上運行，所有作業都將在那裡執行。對於小型測試和少量作業，這是有意義的。但是，在實踐中，經常有多個團隊使用相同的 Jenkins 實例的情況。由於它們有大量的作業，因此在一台實例上執行被認為是不好的做法，原因如下：安全、災難恢復、性能、可擴展性等。

在 Jenkins 中輸入主/從節點：Jenkins 主節點僅用於調度將在 Jenkins 從屬機器上執行的作業。這樣，Jenkins 主機就不會被大量使用，並且團隊擁有自己的從屬機器，其大小最適合他們的測試自動化項目。此外，從屬節點隨後被配置為處理要執行的若干個並行作業（每個節點的執行程序數量）。還可以從 AWS 配置按需節點。這意味著節點僅在需要在其上執行作業時才存在。這非常有用，因為我們想要更大的機器，這些機器只有在運行回歸測試時才會被充分利用。對於這種情況，將在 AWS 上啟動更大的 EC2 實例，作業將在該實例上執行，完成後（基於配置的空閒時間），該實例將在一段時間內保持活動狀態。之後，它將確定在使用按小時付費的服務（例如 AWS 服務）時哪種方式更有優勢。

Jenkins 作業的結構

在 Jenkins CI 服務器中，每個 Jenkins 作業都包含多個部分：

常規：在這裡，我們指定項目/作業名稱/說明，根據需要添加作業參數，定義作業日誌輪換策略等。接下來的屏幕顯示如何配置日誌輪換（您可以指定保留構建日誌的天數或要保留的最後構建日誌的數量），如何參數化作業（通過添加具有默認值0.0.1 的字符串BUILD_ID，但是，此值可以在啟動作業時指定）以及如何配置此作業將在哪裡執行（從屬節點名稱）：
Jenkins 源代碼管理：顧名思義，這是我們在 Jenkins CI 服務器中定義源代碼存儲庫（如 GitHub 或 Subversion）的地方：
Jenkins 構建觸發器：安排作業執行的時間（定期、在其他作業之後、當 GitHub 拉取請求發生時、當更改被推送到 GitHub 時等）。
Jenkins 構建環境：在這裡，我們定義與構建將執行的環境相關的選項（每次執行作業時都刪除工作區，如果掛起一段時間則中止作業……等）。
Jenkins 構建：在 Jenkins CI 服務器中，這是每個作業最重要的步驟。此步驟的結果會影響作業在執行結束時的狀態。根據已安裝的插件，許多選項可用，最常用的插件是：執行 shell、執行 Groovy 腳本、調用 Ant/Maven/Gradle 腳本、執行 Windows 批處理命令等。

這是一個經常使用的“執行 shell”插件的示例，它能夠內聯編寫您自己的 shell 腳本或執行現有的 shell 腳本。
Jenkins 構建後操作：作業的這一部分用於報告作業的結果或在 Jenkins 管道中調用其他作業。一般來說，我們可以發送包含作業執行狀態的電子郵件，可以發布 HTML 報告、JUnit 結果，可以將構建階段構建的工件發佈到 S3 等。

請注意電子郵件主題行中如何指定 $BUILD_ID。由於此作業已參數化，因此此值在啟動此作業時指定。此參數可以在作業的 Jenkins 構建和構建後操作部分中使用。

結論

到目前為止，您已經了解了 Jenkins CI 服務器的主要優勢以及 CI 本身如何添加到軟件開發流程以及測試工程師中。與其他任何技術一樣，需要時間來掌握基礎知識並體驗優勢。我強烈建議您投入時間到 CI 中，從長遠來看，這絕對是值得的。特別是，一旦應用 Jenkins CI 服務器，許多痛苦且重複的流程將被自動化，您將突然有更多時間專注於產品改進。

您的團隊是否也實施了持續集成和 Jenkins CI 服務器？請隨時在評論中分享您團隊的經驗並提出問題！

本文最初發表在 TestProject——測試自動化博客上

關於使用 Jenkins CI 服務器進行持續集成的常見問題

Jenkins 和 Travis CI 的主要區別是什麼？

Jenkins 和 Travis CI 都是流行的持續集成工具，但它們有一些關鍵區別。 Jenkins 是一個自託管解決方案，需要您管理和維護自己的服務器。它高度可定制，可以配置為適應幾乎任何 CI/CD 工作流。另一方面，Travis CI 是一種基於雲的服務，易於設置和使用。它與 GitHub 集成良好，並開箱即用地支持許多語言。但是，對於復雜的工作流，它可能不如 Jenkins 靈活。

Jenkins 與 GitLab CI/CD 相比如何？

Jenkins 和 GitLab CI/CD 都提供強大的持續集成解決方案。 Jenkins 以其靈活性和大型插件生態系統而聞名，而 GitLab CI/CD 則以其與 GitLab 生態系統的無縫集成而受到好評。 GitLab CI/CD 還提供內置的 Docker 支持，這對於使用 Docker 的團隊來說可能是一個很大的優勢。

使用 Jenkins 而不是其他 CI 服務器有哪些優勢？

Jenkins 提供了優於其他 CI 服務器的幾個優勢。它是開源的，並且擁有一個龐大而活躍的社區，這意味著它正在不斷改進和更新。它還擁有龐大的插件生態系統，允許您擴展其功能以滿足您的特定需求。此外，Jenkins 支持各種語言和工具，使其成為許多不同項目的通用選擇。

Jenkins 如何處理 Python 項目的持續集成？

Jenkins 是一款通用的工具，可以處理 Python 項目的持續集成。它可以自動化 Python 應用程序的構建、測試和部署，並且支持許多流行的 Python 測試框架。 Jenkins 還與 Git 等版本控制系統集成良好，使其易於集成到您現有的工作流中。

在 Jenkins 和 Travis CI 之間進行選擇時，關鍵考慮因素是什麼？

在 Jenkins 和 Travis CI 之間進行選擇時，您應該考慮諸如團隊的技術專業知識、CI/CD 工作流的複雜性以及預算等因素。 Jenkins 需要更多設置和維護，但提供更大的靈活性和控制性。 Travis CI 更易於設置和使用，但對於復雜的工作流而言可能不夠靈活。它也是一項付費服務，而 Jenkins 是免費且開源的。