當今的軟件開發行業，單靠一兩個牛人來完成一個個小型軟件的做法早已成爲歷史，規模各異的團隊協同開發已經成爲標配。爲保持代碼在多人開發的情況下的一致性、及早發現代碼的問題，持續集成Continuous Integration（縮寫CI）得到了廣泛的認可與應用。
部分開發人員只是片面的理解與執行CI，但對其原理與價值知之甚少。本文旨在分享XP極限編程與CI持續集成的定位與核心價值，讓每位開發人員都能夠理解其價值，更好的運用。
關於XP極限編程
1.認識作者
極限編程的作者是軟件開發大牛Kent Beck，作爲”十大Java人物”之一，除了XP之外，同時也對設計模式、敏捷、重構、測試驅動開發、JUnit等諸多主題有着巨大的貢獻。他的一系列著作也都是各別領域裏面的經典之作，值得我們深入鑽研、並嘗試實踐來研讀與運用。
2.XP極限編程
極限編程（ExtremeProgramming，簡稱XP）是Agile敏捷開發的典型代表，同時也是十幾種敏捷開發落地方法論中名氣與應用最廣的其中一種（類似的還有Scrum、Kanban等）。XP本質上是輕量級的、迭代式的軟件開發過程。其核心思想是強調人與人之間的協作因素和以敏捷性應對變化。
XP極限編程官方網站：
http://www.extremeprogramming.org/。
包含以下內容：
XP有4個核心價值：
- 溝通(Communication)
- 簡單(Simplicity)
- 反饋(Feedback)
- 勇氣(Courage)。
XP包含了策劃、設計、編程和測試4個活動。
XP的12個最佳實踐是指：
- 規劃策略(The Planning Game)
- 結對編程(Pair programming)
- 測試(Testing)
- 重構(Refactoring)
- 簡單設計(Simple Design)
- 代碼集體所有權(Collective Code Ownership)
- 持續集成(Continuous Integration)
- 現場客戶(On-site Customer)
- 小型發佈(Small Release)
- 每週40小時工作制(40-hour Week)
- 編碼規範(Code Standards)
- 系統隱喻(System Metaphor)。
其中，“持續集成”實踐在編程和測試活動中貫穿進行。
3.XP實踐情況
XP包含12個最佳實踐。早些年在Google等互聯網領頭羊公司內部率先應用推廣，然後不斷輻射，從互聯網擴展到其他行業，從國外擴展到國內。
上述12個實踐之中，超過半數得到了較廣泛的認可與應用。而另外一部分因爲不同企業的文化差異，沒能得到充分使用或者受限使用。比如：結對編程，兩個程序員在一個計算機上共同工作的分工方法。一個人輸入代碼，而另一個人審查他輸入的每一行代碼，利用兩人同時存在相同盲點概率小的思路進行開發，然而，事實上僅在少量特定項目或模塊，或者“老帶新”等特定場景比較有機會實踐這樣的方法。又比如：每週40小時工作制，激烈的競爭下要去實現，更加是一種可望不可即的傳說。
但CI持續集成這一實踐卻得到了廣泛的認可。那些沒有實施CI的公司，要麼是不瞭解，要麼是因資源等原因暫時不具備實施的條件而已。接下來我們詳細說說CI持續集成。
CI持續集成
1.持續集成的定義
Martin Fowler（軟件開發大師，與Kent Beck合著了《Planning Extreme Programming》）對持續集成是這樣定義的：持續集成是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味着每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發佈，自動化測試）來驗證，從而儘快地發現集成錯誤。
2.CI原則
- 所有的開發人員需要在本地機器上做本地構建，然後再提交的版本控制庫中，從而確保他們的變更不會導致持續集成失敗；
- 開發人員每天至少向版本控制庫中提交一次代碼；
- 開發人員每天至少需要從版本控制庫中更新一次代碼到本地機器；
- 需要有專門的集成服務器來執行集成構建,每天要執行多次構建；
- 每次構建都要100%通過；
- 每次構建都可以生成可發佈的產品；
- 修復失敗的構建是優先級最高的事情；
- 測試是未來，未來是測試。
【源自】《Object-Oriented Analysis and Design with applications》
3.CI的價值
大多數人認爲至少包含以下幾個方面：減小風險，減少手動過程，生成構建結果，提升安全感。
事實上CI本身也有成本，主要在於對代碼的維護成本和集成的時間成本。隨着項目進行，軟硬件環境會越來越複雜，代碼也會不斷膨脹。此時，需要團隊而修改或增加原有的測試代碼，以適應這些變化，同時，每次集成所需時間也會變長，CI成本相應增加。
難怪有人說：“這種集成是如此的頻繁，多少次的代碼Commit就有多少次持續集成。前提是集成的成本很低，或者說是完全自動化的”，否則CI本身的成本就很高。
4.持續交付的定義
與CI持續集成相關又特別容易混淆還有另外幾個概念，其中就有持續交付。
持續交付（Continuous delivery，縮寫爲CD）：
是一種軟件工程手法，讓軟件產品的產出過程在一個短週期內完成，以保證軟件可以穩定、持續的保持在隨時可以釋出的狀況。它的目標在於讓軟件的建置、測試與釋出變得更快以及更頻繁。這種方式可以減少軟件開發的成本與時間，減少風險。
CI持續集成是CD持續交付的前提和基礎。這兩者的區分主要有兩點，首先，CI持續集成的範圍較小，主要涵蓋開發人員編碼、自測、與測試人員配合進行的組件級測試。而CD持續交付需要進一步進行SIT集成測試等多環境測試，並由用戶代表在測試環境進行驗證。
除功能之外，還需要進行安全性等一系列非功能性測試，以便“證明該系統或模塊進行了全面驗收，達到了隨時可以上生產的狀態”。其次，CI的測試視角仍是開發視角，檢測代碼或部署包是否有問題，而CD的視角已經轉換爲業務視角，以用戶的身份驗證軟件系統是否滿足需求。
小結
閱讀到這裏，相信大家對XP極限編程與CI持續集成的定位與核心價值有了更加清晰準確的認識。理解正確了，才能更好的進行實踐。歡迎大家一起進行實踐和探討。