最近看了《持續集成－－軟件質量改進和風險降低之道》和馬丁福勒的博客，看書的時候感受不是很深，甚至我覺得我都寫不出這篇讀書筆記。我入職時間不長，進入的項目就在實行CI，很多的CI實踐雖然一知半解，但是由于一直在用，所以書中很多的內容對我來說并不陌生。后來我又去讀了馬丁福勒的博客，有了一些獨特的感受，其中最贊同也感觸最深的話，我用在了標題里，持續集成的主要工作是溝通。作為一種溝通方式，持續集成可以幫助開發人員快速的交流開發內容，及時的發現并且定位問題。

什么是持續集成

持續集成是指頻繁的、經常性的進行代碼的集成構建，當代碼發生變更時，無論變更的大小，都要執行一次構建，進行單元測試，并且與數據庫等進行一次集成。從我所在的項目來說，我們有4個環境，CI環境，QA環境，staging環境，還有生產環境。

QA環境主要用于測試，staging環境可以理解為一個beta版的生產環境，這些環境在這篇文章里都不想過多介紹，主要想要介紹CI環境。

關于CI環境，我的理解就是這是一個最低門檻。所有最新提交的代碼都會最先流入這個環境，這個環境會執行一次build，跑一遍單元測試，執行一遍代碼審查，查看代碼是否可以構建，測試是否都通過，測試覆蓋率是否達標，是否有過多的code smell。所以這個環境也是pipeline掛掉次數最多的環境，所有通過這道門檻的代碼，都是沒有集成問題的代碼，可以直接作為產品進行測試。

持續集成中有一個很重要的點就是要使用專門的集成構建計算機，這也是我在看前幾頁就帶著的一個疑問，直到最后才得到了解答。這個專門的集成構建計算機就是我們項目中的CI環境。這個機器就是為項目創造一個共享的干凈的集成環境。每一個開發者所使用的機器都會有所不同，有硬件和軟件的各種差異，生產環境的各種配置也會與開發者的本地環境有一定差異，我們總要保證提交的代碼是可以在生產環境上工作的，或者是可以在任何一臺機器上工作的。這臺機器就是去排除掉開發者本地環境的種種差異，保證不同的開發者提交的代碼可以共同工作。

那么為什么CI不能和QA環境合并呢？如果二者合并，QA的測試過程可能會被打斷，因為整個環境在構建，整個程序都被停止，為了保證QA可以正常的工作，需要拆出一臺機器或者虛擬機來進行CI的工作。

持續集成的意義

持續集成的好處在于：減少風險、減少重復過程、隨時生成可部署的軟件、給予團隊構建反饋、增強對產品的信心。這幾點好處相信所有提CI的文章都會提到，不過多贅述。

說一下個人的理解，持續集成的意義就是溝通。剛才提到的幾點好處，我在書中讀到過很多次，然而馬丁的這個解釋，詮釋了所有這些好處和CI的意義。為什么說持續集成會降低風險減少重復呢？當多個人在同時開發的時候，可能在同一份文件進行更改，可能做了同樣的操作。當需要對多個人做的這些東西進行合并的時候，如何取舍，怎樣合并一定是一件極端痛苦的事情，所以好多人稱之為“地獄”。

我記得我之前做過一個故事卡，我和另外一組pair的小伙伴做了類似的功能，只是一個很小的功能，合并的過程痛苦不堪，因為我對他們的實現并不了解，解決方案的取舍也是一件艱難的事情，最最痛苦的事情在于花費了時間之后一遍一遍的編譯失敗。

我之所以非常贊同CI的意義就是溝通就在于，當我完成一點代碼，我pull一下代碼庫，跑一下測試，很快就可以知道我的代碼是否與他人有重復，是否可以成功構建。CI實踐讓我不需要隨時跟我的小伙伴進行溝通，就可以快速的知道他們做了什么，我們的代碼是否有沖突、是否有重復，而不是在最后合并的時候，幾個人坐在一起聊自己的代碼，然后痛苦不堪的合并。

通過CI實踐，最后合并的時間幾乎等于沒有，所有提交到CI環境上的代碼都是可集成的代碼，即可部署的軟件，可以幫助團隊快速的部署。就我目前的項目來說，我們幾乎沒有經歷過大規模的merge代碼，經過CI環境之后，QA可以快速的部署到測試環境，測試通過后就可以快速的上線。

CI還有一個很重要的實踐就是反饋。這一點我感受最深的就是在TWU的時候，我們團隊有一個顯示屏，專門用來顯示CI的狀態，當CI掛了的時候，其他人就不會去pull或者push代碼，最后提交代碼的人也會快速去修復。這樣就不會有人因為別人的代碼而反復的定位問題，也不會有多個人同時工作在尋找為何無法成功構建上而導致做了過多重復的工作。

CI的實踐就是一種高效的溝通，不需要言語的表達，也不需要打斷每個人的工作節奏，團隊的成員就會了解到其他人的工作，知道自己接下來應該如何去做。

持續集成與敏捷實踐

持續集成是敏捷實踐的一環，為敏捷實踐中向客戶持續進行交付打下了一定的基礎。在項目中，持續集成的使用很大程度上也反映了團隊的敏捷程度。這一陣子我們團隊進行了敏捷成熟度的評估與改進，有一部分與持續集成密切相關的：

• 開發演示：開發人員是否在充分完成自測后，在部署的開發或測試環境下給測試人員進行當面演示，在主流程和基本場景都通過的前提下測試人員再做完整故事測試
• 代碼評審：團隊是否建立了每天例行的代碼評審機制，對每天提交代碼的質量進行集體評審，并有機制確保評審發現的問題都進行了修復
• 代碼靜態分析：團隊是否利用了工具頻繁（比如每日代碼提交，或每日多次）對提交的代碼質量進行靜態分析，并且團隊能立即對發現的不良問題（嚴重級別以上的問題，高重復率，高復雜度）進行修改，不遺留問題
• 單元測試：開發人員是否為新增和修改的代碼創建了單元測試來驗證其正確性，并且這些單元測試能夠通過持續集成來頻繁地執行，保證持續有效
• 自動化功能測試：團隊是否創建了有效的自動化測試腳本來對組件或系統的功能進行測試（包括服務接口測試和UI測試），并且這些測試腳本能夠通過持續集成來頻繁地執行，保證持續有效；而且團隊遵循“測試金字塔”原則，不同層級的測試有合適的覆蓋范圍
• 自動化非功能管理：團隊是否利用工具模擬對系統或應用的性能，安全性，并發穩定性等非功能性質量進行了驗證，并且這類驗證也是盡可能自動化的，可頻繁執行
• 統一配置管理：團隊是否采用了統一配置管理，即包括應用代碼、單元測試、自動化測試腳本、自動構建腳本、數據庫變更腳本、環境配置等以合理的目錄結構存放在統一的源代碼庫中，全部進行版本化管理
• 單主干開發：開發團隊是否采用了“單主干+發布分支”的分支策略：每天新的代碼頻繁提交到唯一主干，沒有特性分支；在迭代結束時創建或合并到發布分支來為發布提供穩定版本；甚至能直接從主干發布
• 持續集成：團隊是否建立了有效的持續集成流水線，頻繁地自動化地對代碼進行構建，快速獲得反饋；該構建過程應包括編譯、靜態分析、執行各類測試、產生包、各環境自動部署等；構建成功或失敗能立即通知到團隊，一旦失敗團隊能夠立即關注并解決導致錯誤的問題（或回滾代碼）讓構建通過
• 分層構建：針對同一個代碼庫，團隊是否為不同的目的建立了不同層級的持續集成流水線以合理的不同頻率執行不同的任務組合，從而平衡執行頻率和執行效率的矛盾，更快獲得構建反饋
• 環境管理：團隊是否為開發驗證、集成測試、自動化測試、以及預生產發布等各準備了獨立的環境來支持各級驗證環節，且每個環境有明確的目的并隨時穩定可用；最好是這些環境能夠以腳本來定義和自動化變更其配置

其中，開發演示、代碼評審、代碼靜態分析、單元測試、自動化功能管理和自動化菲功能管理屬于評估中質量保證的內容，質量保證的評估總共8項，一半以上都與持續集成有關。其他五項屬于敏捷成熟度評估的持續交付的內容，持續交付中共有7項評估內容，也是一半與持續集成有關。持續集成是敏捷實踐中很重要的一項內容，我的理解是，持續集成對于讓團隊變的敏捷是一個必要條件。