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

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

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

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

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

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

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

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

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

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

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

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

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

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

·???????? 建立分層分級的持續(xù)集成環(huán)境。逐層逐級進行構建，提高構建效率

·???????? 建立有效的產(chǎn)品代碼/用例合入管理規(guī)范。保證代碼/用例及時、準確合入持續(xù)集成庫

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