軟體工程/工具/持續整合簡介
 |
一位華夏公益教科書貢獻者建議將此書籍或章節合併到持續整合軟體開發 中，因為 我們可以製作一本關於該主題的更全面的書籍 請在討論頁面上討論是否應該進行合併。 |
在軟體工程中，持續整合（CI）實施持續的質量控制流程 - 頻繁應用的小部分工作量。持續整合旨在透過取代在完成所有開發後才進行質量控制的傳統做法，來提高軟體質量並縮短交付時間。
在開始更改時，開發人員會獲取當前程式碼庫的副本進行操作。當其他開發人員將更改後的程式碼提交到程式碼倉庫時，此副本逐漸不再反映倉庫程式碼。當開發人員將程式碼提交到倉庫時，他們必須首先更新自己的程式碼以反映倉庫中自獲取副本以來的更改。倉庫包含的更改越多，開發人員在提交自己的更改之前就必須完成的工作越多。
最終，倉庫可能會與開發人員的基線程式碼相差很大，以至於他們進入所謂的“整合地獄”[1]，在這種情況下，整合所需的時間超過了最初進行更改的時間。在最壞的情況下，開發人員可能不得不放棄更改並完全重新進行工作。
持續整合涉及儘早且頻繁地整合，以避免“整合地獄”的陷阱。該實踐旨在減少返工，從而降低成本和時間。
本文的其餘部分討論瞭如何實現持續整合的最佳實踐，以及如何自動化此實踐。自動化本身就是最佳實踐。 [2][3]
持續整合 - 作為頻繁地將新的或更改的程式碼與現有程式碼倉庫進行整合的做法 - 應該足夠頻繁，以至於在提交和構建之間沒有任何間隙，並且這樣一來，任何錯誤都不會在開發人員注意到並立即糾正它們之前出現。 [4] 正常的做法是透過每次提交到倉庫來觸發這些構建，而不是透過定期安排的構建。在快速提交的多開發人員環境中這樣做，實際上是需要在每次提交之後觸發一個簡短的計時器，然後在計時器到期或上次構建之後經過相當長的時間後開始構建。CruiseControl 或 Hudson 等自動化工具可以自動提供此排程功能。
另一個因素是需要一個支援原子提交的版本控制系統，即開發人員的所有更改都應該被視為單個提交操作。嘗試僅從更改了一半的檔案進行構建毫無意義。
此實踐提倡使用修訂控制系統來管理專案的原始碼。所有構建專案所需的工件都應該放置在倉庫中。在此實踐以及修訂控制社群中，慣例是系統應該能夠從全新的檢出構建，並且不需要額外的依賴項。極限程式設計倡導者 Martin Fowler 還提到，在工具支援分支的情況下，應該儘量減少其使用 [需要引證]。相反，更傾向於將更改整合在一起，而不是同時維護軟體的多個版本。主幹應該作為軟體工作版本的存放位置。
單個命令應該具有構建系統的能力。許多構建工具，例如 make，已經存在多年。其他更新的工具，例如 Ant、Maven、MSBuild 或 IBM Rational Build Forge，在持續整合環境中被頻繁使用。構建的自動化應該包括整合過程的自動化，這通常包括部署到類似於生產環境的環境中。在許多情況下，構建指令碼不僅會編譯二進位制檔案，還會生成文件、網站頁面、統計資料和分發媒體（例如 Windows MSI 檔案、RPM 或 DEB 檔案）。
構建程式碼後，所有測試都應執行以確認其行為符合開發人員的預期。
透過定期提交，每個提交者都可以減少衝突更改的數量。簽入一週的工作可能會導致與其他功能發生衝突，並且可能非常難以解決。系統某個區域的早期、小的衝突會導致團隊成員互相交流他們正在進行的更改。
許多程式設計師建議每天至少提交一次更改（每構建一個功能一次），此外還要執行夜間構建。
系統應該將提交構建到當前工作版本，以驗證它們是否可以正確整合。常見的做法是使用自動化持續整合，但也可以手動進行。對於許多人來說，持續整合等同於使用自動化持續整合，其中持續整合伺服器或守護程序監控版本控制系統以檢視是否有更改，然後自動執行構建過程。
構建需要快速完成，以便如果整合出現問題，可以迅速識別。
擁有一個測試環境可能會導致測試系統在生產環境中部署時出現故障，因為生產環境可能與測試環境存在很大差異。但是，構建生產環境的副本成本很高。相反，應該構建一個可擴充套件版本的實際生產環境，以在保持技術堆疊組合和細微差別的同時，減輕成本。
使構建物易於供利益相關者和測試人員使用，可以減少重建不符合要求的功能時所需的工作量。此外，早期測試可以減少缺陷在部署前存活的可能性。在早期發現錯誤，在某些情況下，也減少了解決錯誤所需的工作量。
應該很容易找到構建在哪裡/是否中斷以及誰進行了相關更改。
大多數 CI 系統允許在構建完成後執行指令碼。在大多數情況下，可以編寫一個指令碼將應用程式部署到一個每個人都可以檢視的即時測試伺服器上。這種思維方式的進一步發展是持續部署，它要求軟體直接部署到生產環境，通常使用額外的自動化來防止缺陷或迴歸[5]。
持續整合起源於極限程式設計 (XP) 社群，XP 倡導者 Martin Fowler 和 Kent Beck 於 1999 年左右首次撰寫了關於持續整合的文章。Fowler 的論文[6] 是有關該主題的流行資訊來源。Beck 的書《極限程式設計解析》[7]，極限程式設計的原始參考，也描述了該術語。
持續整合有很多優點
- 當單元測試失敗或出現錯誤時，開發人員可能會將程式碼庫恢復到無錯誤狀態，而不會浪費時間進行除錯。
- 開發人員持續檢測和修復整合問題 - 避免在釋出日期（當每個人都嘗試簽入他們略有不相容的版本時）出現最後一分鐘的混亂。
- 早期預警不完整/不相容的程式碼
- 早期預警衝突的更改
- 立即對所有更改進行單元測試
- 持續提供“當前”構建以供測試、演示或釋出目的
- 立即向開發人員反饋他們正在編寫的程式碼的質量、功能或系統範圍的影響
- 頻繁的程式碼簽入促使開發人員建立模組化、不太複雜的程式碼[需要引用]
- 從自動化測試和 CI 生成的指標（例如程式碼覆蓋率、程式碼複雜度和功能完整的指標）使開發人員專注於開發功能性、高質量的程式碼，並有助於在團隊中形成發展勢頭[需要引用]
- 需要初始設定時間
- 需要完善的測試套件才能實現自動化測試的優勢
- 由於程式碼庫不斷變化，大規模重構可能會很麻煩
- 構建機器的硬體成本可能很高
許多使用 CI 的團隊報告說，CI 的優勢遠遠超過缺點。[8] 在開發過程的早期發現並修復整合錯誤，在專案的整個生命週期內節省了時間和金錢。
為了支援持續整合，可以使用自動化構建軟體等軟體工具。
持續整合的軟體工具包括
- AnthillPro — Urbancode 的持續整合伺服器
- Apache Continuum — 支援 Apache Maven 和 Apache Ant 的持續整合伺服器。支援 CVS、Subversion、Ant、Maven 和 shell 指令碼
- Apache Gump — Apache 的持續整合工具
- Automated Build Studio — AutomatedQA 的專有自動化構建、持續整合和釋出管理系統
- Bamboo — Atlassian Software Systems 的專有持續整合伺服器
- BuildBot — 基於 Python/Twisted 的持續構建系統
- BuildForge - IBM / Rational 的專有自動化構建引擎
- BuildMaster — Inedo 的專有應用程式生命週期管理和持續整合工具
- CABIE - Continuous Automated Build and Integration Environment — 開源，用 Perl 編寫；與 CVS、Subversion、AccuRev、Bazaar 和 Perforce 協同工作
- Cascade — 專有持續整合工具；提供一個檢查點設施來構建和測試更改，然後再提交它們
- codeBeamer — 具有內建持續整合功能的專有協作軟體
- CruiseControl — 用於持續構建過程的基於 Java 的框架
- CruiseControl.NET — 基於 .NET 的自動化持續整合伺服器
- CruiseControl.rb - 輕量級、基於 Ruby 的持續整合伺服器，可以構建任何程式碼庫，而不僅僅是 Ruby，在 Apache Licence 2.0 下發布
- ElectricCommander — 來自 Electric Cloud 的專有持續整合和釋出管理解決方案
- FinalBuilder Server — VSoft Technologies 的專有自動化構建和持續整合伺服器
- Go — Thoughtworks 的專有敏捷構建和釋出管理軟體
- Jenkins（以前稱為 Hudson） — 採用 MIT 許可，用 Java 編寫，在 servlet 容器中執行，支援 CVS、Subversion、Mercurial、Git、StarTeam、Clearcase、Ant、NAnt、Maven 和 shell 指令碼
- Software Configuration and Library Manager — IBM Rational Software 為 z/OS 提供的軟體配置管理系統
- QuickBuild - 專有持續整合伺服器，具有免費的社群版，提供構建生命週期管理和提交前驗證功能。
- TeamCity — JetBrains 的專有持續整合伺服器，具有免費的專業版
- Team Foundation Server — Microsoft 的專有持續整合伺服器和原始碼儲存庫
- Tinderbox — 基於 Mozilla 的產品，用 Perl 編寫
- Rational Team Concert — IBM 的專有軟體開發協作平臺，具有內建的構建引擎，包括 Rational Build Forge
請參閱持續整合軟體比較，以獲得更深入的功能矩陣。
- Duvall，Paul M. (2007)。持續整合。改進軟體質量和降低風險。Addison-Wesley。 ISBN 0-321-33638-0.
- ↑ 坎寧安，沃德 (2009 年 8 月 5 日). "整合地獄". WikiWikiWeb. 檢索於 2009 年 9 月 19 日.
{{cite web}}: 檢查日期值：|accessdate=和|date=(幫助) - ↑ 布勞內斯，大衛 (2010 年 1 月 1 日). "[OSLC 可能的新工作組 - 自動化"]。open-services.net 社群郵件列表. http://open-services.net/pipermail/community_open-services.net/2010-January/000214.html. 檢索於 2010 年 2 月 16 日.
- ↑ 泰勒，布拉德利. "使用 ShadowPuppet 和 Capistrano 進行 Rails 部署和自動化".
- ↑ 福勒，馬丁. "持續整合". 檢索於 2009-11-11.
- ↑ 參見 5 個簡單步驟的持續部署 - O'Reilly 雷達 和 IMVU 的持續部署：每天完成 50 次不可能的任務 - 蒂莫西·菲茨
- ↑ 福勒，馬丁. "持續整合".
- ↑ 貝克，肯特 (1999). 極限程式設計解釋. ISBN 0-201-61641-6.
- ↑ 理查德森，賈裡德 (2008 年 9 月). "無廢話，只講乾貨大會上的敏捷測試策略". 馬薩諸塞州波士頓. http://www.nofluffjuststuff.com.
- 持續整合軟體比較
- 持續整合 由馬丁·福勒（簡介）
- 波特蘭模式庫中的持續整合 （協作討論）
- 波特蘭模式庫中的跨平臺測試
- 持續整合伺服器功能矩陣 （工具指南）
- 持續整合：優秀團隊的基石 由賈裡德·理查德森（簡介）
- 構建可維護性和可重用性的秘訣 由傑伊·弗勞爾斯
- 持續整合反模式 由保羅·杜瓦爾
- 極限程式設計