持續集成理論和實(shí)踐的新進(jìn)展(2)

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

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

　　分階段構建(Staged Build)

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

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

　　構建流程可視化

　　通過(guò)分階段并發(fā)構建來(lái)縮短反饋周期

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

　　報告

　　作者在第二版中專(zhuān)門(mén)拿出一節“每個(gè)人都能看到進(jìn)度(Everyone Can See What's Happening)”來(lái)介紹有關(guān)持續集成報告的內容。因為：

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

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

　　對于溝通的重視從工具的角度也可以體現出來(lái)。Cruise Control最主要做的事情是任務(wù)調度，在報告部分做的相對來(lái)說(shuō)非常粗糙，比較有價(jià)值的報告大部分是從Cruise移植過(guò)去的。Cruise在從一開(kāi)始就非常重視這一點(diǎn)，通過(guò)Cruise你可以非常清晰地知道，代碼發(fā)生了什么變化、正在進(jìn)行的構建的狀態(tài)和歷史構建的狀態(tài)。網(wǎng)頁(yè)的形式對于分布式團隊來(lái)說(shuō)具有不可替代的優(yōu)勢。

　　正如我們前面所說(shuō)的，音樂(lè )、熔巖燈等物理手段，具有更強的信息輻射能力。站起來(lái)往周?chē)匆豢淳椭滥膫€(gè)團隊的構建成功了，哪個(gè)失敗了。

　　持續部署

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

　　你應該有一個(gè)腳本幫助你很容易地將系統部署到生產(chǎn)環(huán)境中去。......同時(shí)要特別考慮的是要能夠自動(dòng)回滾。

　　引入持續集成的建議

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

　　引入版本控制。

　　實(shí)現自動(dòng)化構建。

　　添加自動(dòng)化測試。

　　加快提交構建。

　　尋找幫助。(比如ThoughtWorks)

　　第二部分 持續集成領(lǐng)域的新進(jìn)展

　　正如前文所說(shuō)，ThoughtWorks中國公司在過(guò)去的幾年里面對于持續集成實(shí)踐和幫助客戶(hù)實(shí)施持續集成都積累了很多的經(jīng)驗，同時(shí)在理論體系方面也更加豐富完整。這也使ThoughtWorks在這個(gè)領(lǐng)域繼續保持了行業(yè)領(lǐng)先的位置。

　　正如我們在第一部分講到的，持續集成不應該只作為一個(gè)孤立的實(shí)踐來(lái)應用。我們的經(jīng)驗表明如果只把持續集成作為一個(gè)孤立的實(shí)踐應用很難從持續集成長(cháng)期受益。持續集成往往進(jìn)入“長(cháng)紅”或者“長(cháng)綠”的不正常的狀態(tài)。長(cháng)紅意味著(zhù)系統長(cháng)期無(wú)法集成;長(cháng)綠則往往意味著(zhù)缺少足夠的驗證。為了術(shù)語(yǔ)上的澄清，我們明確地將持續集成的定義區分為狹義的持續集成和廣義的持續集成。

　　狹義的持續集成：基于某種或者某些變化對系統進(jìn)行的經(jīng)常性的構建活動(dòng)。

　　廣義的持續集成：軟件開(kāi)發(fā)團隊在上述活動(dòng)的約束下所采用的開(kāi)發(fā)流程。

　　狹義的持續集成

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

　　持續檢查

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

　　持續編譯

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

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

　　持續驗證

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

　　持續部署

　　于大型軟件應用來(lái)說(shuō)，部署往往是一個(gè)費時(shí)費力又容易出錯的步驟，因為這里面涉及到數據遷移、版本兼容等各種棘手的問(wèn)題。持續部署的思想是將這些工作標準化自動(dòng)化，使其能夠可靠地、自動(dòng)地、快速地運行。持續部署是當前DevOps運動(dòng)中的熱門(mén)話(huà)題之一。

　　持續基礎設施集成

　　現代大型軟件開(kāi)發(fā)，尤其是互聯(lián)網(wǎng)應用開(kāi)發(fā)中經(jīng)常依賴(lài)于一些常見(jiàn)的基礎設施——比如Spring、Tomcat、Database等等。這些基礎設施發(fā)生變化的時(shí)候，我們應當及時(shí)地觸發(fā)持續集成，以確保我們的系統是能夠與新的基礎設施一起工作的。

　　持續報告

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

原文轉自：http://kb.cnblogs.com/page/109735/