敏捷開發的優秀實踐中非常重要的一個實踐就是持續集成（Continuous integration）。持續集成通過每日至少一次的自動構建，完成代碼編譯，自動執行自動化測試用例，構建完成后自動輸出構建報告。在敏捷開發的迭代開發過程中堅持持續集成，可以將集成工作進行分散并提前，通過逐步合入通過功能驗證的代碼，既能在早期就發現和解決問題，降低問題解決成本，提高問題解決效率，同時也有效避免了在產品最終集成時問題的集中爆發。

在某公司的敏捷開發項目中，持續集成庫大部分時間都是處理構建失敗的狀態。無論是管理者還是研發人員，都對此抱怨不斷，卻沒有好的辦法來應對。管理者認為持續集成工具不好，開發人員能力也不夠，持續集成庫沒有起到應有的作用。少部分研發人員認為持續集成已經是象征意義大于實際作用，作用不大，不過大部分研發人員還是認為持續集成是個很好的工具，就是應用很麻煩，上代碼成了一件苦差事，為了每天的代碼能通過持續集成，每天都要加班到很晚才能回去，感覺很累，對持續集成也產生了一絲迷茫。

為何一個好好的實踐不僅沒有起到應有的作用，反而遭到了大家的質疑，甚至成了工作的阻礙因素，降低了工作效率？通過對其他敏捷開發項目的調研，發現都存在類似問題。經過分析總結，大致可以分為以下幾個方面的問題：

·???????? 持續集成構建失敗的原因定位困難，責任難以區分。代碼定位信息少，開發人員拿到構建失敗錯誤信息難以迅速確認問題根源所在，甚至難以定位出錯模塊，各模塊互相推拖責任

·???????? 代碼/用例集中上庫。平時持續集成庫大部分時候處于失敗狀態，開發人員一般不能把代碼合入，只能在迭代接近結束需要驗證時才集中將代碼/用例上庫，然后按照構建失敗信息依次攻關解決問題。同時由于不是及時上庫，上庫時出現漏合代碼，或者用例沒有同步合入

·???????? 修改代碼異步上庫問題。有些問題的修改涉及多個模塊，問題修改責任人匯總各模塊修改代碼，在本地構建通過，與各模塊修改人約好上庫時間后代碼上庫，但其他模塊因為某種原因代碼沒有及時上庫

·???????? 整體責任意識不夠。部分人員把持續集成當成了測試工具，在未經過本地充分驗證的情況下就把代碼和用例上到集成庫

·???????? 代碼配合問題。修改接口函數，沒有通告相關使用人員，導致其他模塊調用該接口失敗

·???????? 代碼被覆蓋問題。代碼上庫了，當時構建成功，但晚上再次構建或者隔天構建時卻發現構建失敗，經過代碼排查發現前面修改的代碼被其他開發人員合入時覆蓋掉了

·???????? 自動化用例質量不高。對單元/集成測試用例腳本質量重視不夠，用例點覆蓋不夠全面，或者用例構建不能涵蓋場景，在本地驗證時未能發現問題，在上升到系統集成層面問題才突然爆發出來

那么該如何才能將持續集成的作用真正發掘出來，使之成為開發人員提高效率、提升質量的利器呢？

首先應該從管理上重視起來，持續集成的通過與否與應該放到一個比較高的層次來看待。及時修復失敗的構建。這需要作為團隊最高優先級的工作，團隊成員必須在最短時間內響應并修復，不能定位的需要盡快求助

其次應該建立起持續集成配套的保障措施，強化開發人員一次性做好事情的意識

·???????? 持續集成狀態可視化，報告信息全面。這樣可以及時跟蹤持續集成狀態，在構建失敗的情況利用狀態報告以及日志等信息來協助研發人員快速定位構建失敗原因

·???????? 建立分層分級的持續集成環境。逐層逐級進行構建，提高構建效率

·???????? 建立有效的產品代碼/用例合入管理規范。保證代碼/用例及時、準確合入持續集成庫

·???????? 建立完備和準確的自動化單元測試和集成測試腳本。這是持續集成的質量保障