持續集成（
Continuous Integration
）
?
?
持續集成（
Continuous Integration
），縮寫為
CI
p
是一項
軟件開發實踐
，其中團隊的成員經常集成他們的工作，通常每個人每天至少集成一次
——
這導致每天會
集成多次
。每次集成是通過
自動化的構建
（包括測試）進行的，目的是盡快地檢查
集成錯誤
。許多團隊發現這樣做能夠減少大量的集成問題，讓團隊能夠更快的開發一致的軟件。
p
自動化的構建：
獲取版本、編譯、單元測試、靜態檢查、集成測試、系統測試、軟件部署、信息反饋等全部自動化。
持續集成是沒有任何爭議的業界優秀實踐
?
版本控制庫、
CI(
持續集成
)
服務器、構建腳本、反饋機制
?
開發人員日常工作步驟：
①
開發人員基于最新版本開發
1
個新特性
②
從配置庫上將更新過的文件同步到本地，確保本地代碼和庫文件是最新的
③
在本地完成編譯、單元測試、代碼靜態檢查
④
準備提交代碼前再次從配置庫上將更新過的文件同步到本地
⑤
再次在本地完成編譯、單元測試、代碼靜態檢查
⑥
成功后向配置庫提交代碼，自動觸發
CI
集成服務器的一次構建，構建失敗后要立即修復直到構建成功
⑦
推薦采用令牌方式提交代碼
?
?
本地構建是開發人員自我質量保證、持續集成質量和版本質量的基礎
?
?
?
微軟
p
持續集成人員占開發人員的
1%
，如微軟
2000
人的
windows
部門，有
20
人專職做持續集成
p
check in
是頭等大事
，認為對
check in
都不認真，那么就沒什么事能認真作了。
如果
check in
的代碼
Build
（持續集成）不通過，
24
小時任何時間通知，必須回公司修正；
2
次
Build
不通過會導致責任人在項目組壓力非常大，甚至呆不下去。
?
Ericsson
p
愛立信
CTO HAKAN
認為愛立信產品
交付周期縮短
50%
，效率不斷提升的三個
法寶
是
Daily build
（持續集成）
，
Streamline
以及
One track
。
p
E
公司版本構建
3
次不通過開發經理將被轉崗！
?
業界
持續集成招聘
崗位
是軟件開發
崗位
的
0.7%
p
業界招聘信息看，持續集成崗位的發展速度是軟件開發崗位的
5
倍，招聘崗位是軟件開發的
0.7%
。
?
?
?
開發效率提升
30%
?
開發成本節約
30
％
?
錯誤減少
30%
?
構建速度提升
100%
?
配置效率提升
40%
?
發布頻率提升
40%
?
大型項目的效率提升更大
全球
81.7%
的軟件項目采用持續集成
?
?
?
每天生成可部署的軟件，避免產品最終集成時爆發大量問題
p
缺陷的檢測和修復變得更快
p
軟件的健康程度可以度量
?
團隊成員每天都看到自己的可工作的軟件成果，增強自信心
?
?
持續集成可以
真實
的
反映產品
的
開發進度
p
可以工作的軟件是衡量進度的唯一標準。
p
在傳統的集成模式下，
“
最后
10%
的工作仍需要
90%
的時間完成
”
。
p
實施持續集成的團隊，進度通過特性的完成率來表示，
90%
的完成率意味著
90%
的特性開發測試完畢。
?
持續集成是產品開發的
“
心跳
”
，是產品質量的
晴雨表
p
開發人員每天的工作都立刻合入版本，構建結果快速反饋給項目經理，項目過程質量一目了然，管理者可以度量真實的進度和質量，確定風險，并積極地進行風險控制。
?
增強開發人員
自信心
p
每次代碼修改，團隊成員都知道自己的軟件遵守編碼標準和設計標準，通過測試驗證，往前邁進的每一步都非常堅實。
p
任務越小，工作越輕松。
?
?
持續集成!
=
持續編譯
持續集成!
=
工具
+
技術
持續集成!只是開發人員的事情
?
?
任何一點集成方面的努力都是值得肯定的
,
哪怕即使只是持續編譯，只要保證每天都能夠編譯通過，也已經具有很大的價值了。
?
持續集成關鍵是：
持續測試
。即持續集成在很大程度上依賴測試策略和自動化程度。
?
?
?
持續集成的內涵更多是軟件開發理念，絕非只是工具和技術
p
持續集成的技術和工具能做的就是自動提供快速反饋
p
團隊收到反饋之后的行為
,
才是降低風險
,
提高質量的關鍵
p
持續集成更多的是一種開發文化：
工作完成的唯一標準是構建成功
?
?
?
持續集成更多的是管理（需要管理者下決心），例如制定產品級別的集成策略，包括：
p
專用的持續集成硬件環境
p
導致主干版本構建失敗的行為要嚴懲
p
修復失敗的構建是最高優先級的事情
p
經常（每天多次）提交代碼，提交代碼前執行足夠多的測試保證質量
p
編寫自動化的測試用例（
UT
、
IT
、
ST
）
p
每次構建必須通過所有測試和審查
?
?
?
解決
版本構建失敗的
問題是
團隊
最高優先級任務
p
最近提交代碼的開發者必須參與修復失敗的構建
p
短期內不能修復的構建代碼必須回滾
?
開發人員應
每天提交至少一次代碼
p
每天至少向版本控制庫提交一次代碼。頻繁的提交將促使開發人員把工作分解成更小的粒度，既降低工作難度，又有利于監控項目的進展。
?
自己提交
的
代碼不能導致
其他成員的
代碼構建失敗
p
不要提交無法編譯或不能通過測試的代碼
p
開發人員提交代碼前必須做本地構建，確保合入代碼正確
?
開發人員
不僅開發代碼
，
更要編寫自動化測試用例
p
開發人員不僅開發代碼，同時要編寫自動化的
UT
、
IT
的測試用例來驗證軟件
p
開發人員要持續維護和更新自動化測試用例
?
開發人員須
先在本地構建成功，才可提交代碼到配置庫
p
代碼提交到版本控制前；所有代碼都必須遵守通用的編碼和設計標準，包括編譯、
PCLINT
檢查，編程規范檢查，常見錯誤檢查，復雜度檢查，重復代碼檢查、
UT
測試
100%
通過等。
?
始終保證主干版本的構建成功
p
保持所有人工作在主干版本上，并且始終保持其能構建成功
p
永遠不要讓主干版本長期處于
build
不通過的狀態
?
不要在下班的時候留下失敗的構建
?
不要在失敗的構建上更新、提交代碼
?
?
?
開發、測試及設計共同負責（參與測試場景討論、測試策略制定、測試結果分析）
?
功能測試用例能夠及時納入持續集成環境
p
自動化測試設計和實現，與產品代碼開發并行
p
自動化測試用例在本地調試通過后及時納入持續集成環境，以便盡早的執行用例發現問題
?
持續集成環境中測試失敗導致構建失敗
p
構建成功標準包括自動化測試用例
100%
通過
p
導致構建失敗的用例開發和測試要共同關注并及時修復
?
?
?
管理者重要職責是審視持續集成的結果
，出現問題促使盡快解決
p
從關注計劃、文檔到
關注持續集成結果
的轉變，持續集成反映了產品真實的進度和質量。
?
保證持續集成人力投入，產品持續集成有
專人負責
，其職責：
p
負責制定產品分級分層分布式的產品持續集成策略
p
負責持續集成環境的搭建和維護
p
負責維護產品的模塊依賴關系（如
Makerfile
、測試執行的順序）
p
提供在各種不同環境下（如操作系統、硬件配置、軟件配置）的工具配置和使用
p
及時定位和解決持續集成環境存在的問題
?
負責產品持續集成的專人應當是
資深員工
而
不是沒有經驗的員工
p
持續集成需要對產品架構、模塊依賴關系、開發活動順序、環境部署、配置庫等都非常熟悉的人才可以制定出正確的產品持續集成策略。
p
持續集成是系統工程，涉及設計、開發、測試、工具、技術等之間協同，需要對產品有系統視野的人。
?
?
n
實踐
1
：單一的代碼源，所有軟件資產集中管理；
n
實踐
2
：經常提交代碼，每天至少提交一次代碼；
n
實踐
3
：不要提交無法構建的代碼，提交代碼之前先執行本地構建；
n
實踐
4
：構建過程完全自動化；
n
實踐
5
：每次變更都要觸發一次集成構建，在一臺獨立的構建機器上；
n
實踐
6
：立即修復無法通過的構建；
n
實踐
7
：使構建足夠快，必要的話，采用分級構建策略；
n
實踐
8
：將軟件部署到接近真實的環境上進行測試；
n
實踐
9
：任何人可隨時取到最新的可執行程序；
n
實踐
10
：所有人都知道最新的構建狀態；
?
?
?
持續集成（Continuous Integration），
