淺談敏捷開發(fā)之如何提升持續(xù)集成效率

發(fā)布日期:
2017-10-06

瀏覽次數(shù):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相關推薦