持續集成理論和實踐的新進展(2)

　　任何人都可以找到一臺干凈的機器，連上網，通過一個命令就可以取得要構建所開發的系統需要的所有源文件。

　　第二版中的原則增加了對構建的支持6：

　　任何人都可以找到一臺干凈的機器，做一次取出(checkout)動作，然后對系統執行一次完整的構建。

　　3) 分階段構建(Staged Build)

　　分階段構建是Cruise(已經更名為Go)引入的重要概念。其主要的意義在于：

　　分離關注度不同的驗證階段，比如Commit Build和Regression Tests，團隊會對不同的驗證階段采取不同的策略

　　構建流程可視化

　　通過分階段并發構建來縮短反饋周期

　　當構建的時間過長時，我們通常會要求開發人員只運行速度較快的價值較高的構建階段就可以繼續自己的開發任務，而不必等待漫長的次級構建完成。這里作者提到ThoughtWorks不同的團隊有很多有趣的實踐，我們將在第二部分向讀者介紹其中的一部分。

　　報告

　　作者在第二版中專門拿出一節“每個人都能看到進度(Everyone Can See What’s Happening)”來介紹有關持續集成報告的內容。因為：

　　持續集成的目的是為了溝通。

　　這是第二版相對于第一版來說一個非常明顯的變化。在第一版中通知的手段還主要是電子郵件，實際上在作者撰寫第二版的時候，ThoughtWorks已經不贊成將電子郵件作為主要的持續集成通知工具了。更好的溝通工具包括音樂、熔巖燈、顯示器等。

　　對于溝通的重視從工具的角度也可以體現出來。Cruise Control最主要做的事情是任務調度，在報告部分做的相對來說非常粗糙，比較有價值的報告大部分是從Cruise移植過去的。Cruise在從一開始 就非常重視這一點，通過Cruise你可以非常清晰地知道，代碼發生了什么變化、正在進行的構建的狀態和歷史構建的狀態。網頁的形式對于分布式團隊來說具 有不可替代的優勢。

　　正如我們前面所說的，音樂、熔巖燈等物理手段，具有更強的信息輻射能力。站起來往周圍看一看就知道哪個團隊的構建成功了，哪個失敗了。

　　4) 持續部署

　　持續集成實踐有一個基本的思想就是：越是痛苦的事情，越要經常做。集成之后更令人心驚膽顫的事情就是——部署。部署到生產環境的流程通常要嚴格得多，然而所有的工作必須經歷了生產環境的驗證才算是成功的，所以——持續部署才是王道。Martin在第二版中建議：

　　你應該有一個腳本幫助你很容易地將系統部署到生產環境中去。……同時要特別考慮的是要能夠自動回滾。

　　引入持續集成的建議

　　作者在第二版中特別給出了逐步引入持續集成的建議。包括：

　　引入版本控制。

　　實現自動化構建。

　　添加自動化測試。

　　加快提交構建。

　　尋找幫助。(比如ThoughtWorks)

　　第二部分 持續集成領域的新進展

　　正如前文所說，ThoughtWorks中國公司在過去的幾年里面對于持續集成實踐和幫助客戶實施持續集成都積累了很多的經驗，同時在理論體系方面也更加豐富完整。這也使ThoughtWorks在這個領域繼續保持了行業領先的位置。

　　正如我們在第一部分講到的，持續集成不應該只作為一個孤立的實踐來應用。我們的經驗表明如果只把持續集成作為一個孤立的實踐應用很難從持續集成長期 受益。持續集成往往進入“長紅”或者“長綠”的不正常的狀態。長紅意味著系統長期無法集成;長綠則往往意味著缺少足夠的驗證。為了術語上的澄清，我們明確 地將持續集成的定義區分為狹義的持續集成和廣義的持續集成。

　　狹義的持續集成：基于某種或者某些變化對系統進行的經常性的構建活動。

　　廣義的持續集成：軟件開發團隊在上述活動的約束下所采用的開發流程。

　　1) 狹義的持續集成

　　一般來說，狹義的持續集成包括如下幾個方面：持續檢查、持續編譯(鏈接)、持續驗證、持續部署、持續基礎設施、持續報告等6個方面。

　　持續檢查

　　持續檢查的目的是保證代碼風格一致，主要關注于代碼的靜態質量和內部質量，比如變量命名方式、大括號位置等等。大部分的現代集成開發環境(IDE) 都具備實時檢查代碼質量的功能。為了保證主線上的代碼質量能夠達到一致的標準，應當在持續集成腳本中加入靜態檢查階段。比如，Java的PMD、 FindBugs等等。

　　持續編譯

　　持續編譯是一個很樸素的想法，就是保證主線上的代碼始終處于可編譯的狀態。但是這對于很多大中型團隊來說卻并非想當然的簡單。這是因為很多團隊并未 采用集體代碼所有權策略，導致存在依賴的團隊的代碼無法編譯。針對這樣的問題，一方面我們建議采用集體代碼所有權;另一方面，對于確實因為安全原因需要隔 離的代碼應該邊界、明確接口，很少存在大部分代碼需要對大部分人保密的情況。

　　持續檢查和持續編譯是持續集成中最基本的驗證手段。

　　持續驗證

　　持續驗證的目的是檢查主線上的代碼是否能夠實現所要求的功能，或者已有的功能是否被破壞。在大部分的構建中，驗證部分是耗時最長、成本最高的部分， 但同時也是收益最大的部分。在這個階段，我們看到的主要問題是驗證不充分和驗證時間過長。針對這樣的問題，我們通常采用分層分級的持續集成策略。后面有詳 細的描述。

　　持續部署

　　對于大型軟件應用來說，部署往往是一個費時費力又容易出錯的步驟，因為這里面涉及到數據遷移、版本兼容等各種棘手的問題。持續部署的思想是將這些工作標準化自動化，使其能夠可靠地、自動地、快速地運行。持續部署是當前DevOps運動中的熱門話題之一。

　　持續基礎設施集成

　　現代大型軟件開發，尤其是互聯網應用開發中經常依賴于一些常見的基礎設施——比如Spring、Tomcat、Database等等。這些基礎設施發生變化的時候，我們應當及時地觸發持續集成，以確保我們的系統是能夠與新的基礎設施一起工作的。

　　持續報告

　　報告是將持續集成的狀態以適當的形式展現給干系人的基本手段。報告是持續集成的晴雨表，所以它必須直觀、易懂，而且對關注點不同的角色展現不同的內 容和粒度。比如，開發人員可能更關心錯誤的日志;項目經理可能更關心測試覆蓋率;產品經理可能更關心持續集成通過率的趨勢等等。

原文轉自：http://www.wangyuxiong.com/archives/51243