這是《落葉》文集里第 339 片落葉，希望你能喜歡，不為別的，只為這份堅持。
【提問】
原來這就是持續集成啊？
【舊識】
很多年前在做項目的時候，其實就已經接觸到了持續集成，只是那時候好像沒有這么一種叫法，或者說也沒現在處于互聯網產品時代的這么火熱，所以，有相當長的一段時間，一直認為持續集成是個新生事物，自己一直都沒有接觸過它，很神秘。
那時候只是很簡單的目的，為了方便、快速地生成可部署、可測試的包。
這不就是自動構建嗎？
那時候，項目開始的時候，就會建立一個新的 branch，開發寫完某個功能，或者修復完一個 bug，就將 code check-in 到對應的版本分支里，根據開發和測試的計劃，大概在代碼集成階段就會在一個 web 端的 build 系統里去創建 Daily Build Job，每天在中國時間的凌晨開始，系統自動檢測 svn 里對應分支是否有代碼更新，并從中 check-out 最新的 code，然后構建成 build。如果構建出錯了，會生成 build failed log，能通過日子定位到相關的代碼和開發工程師。測試工程師早上來上班第一件事，就是從 build server 上下載最新的 build，然后部署，開始一天的測試工作。
這不就是自動部署嗎？
后來，測試工程師為了提升工作效率，想讓自己一到辦公室就可以開始測試，于是基于這個 Auto Build 系統，又開發了 Auto Deployment 腳本，自動檢測是否有最新的包，有的話就去下載并自動安裝。
這不就是自動驗證嗎？
再后來，測試工程師為了再次提升工作價值，讓自己每天聚焦在更有意義的 bug 深度挖掘工作上，又將 BVT Automation 集成了進去，當自動部署完成之后，自動執行 BVT TA 腳本，用于檢測最新的構建包是否存在一些很淺顯的和阻礙性的缺陷。
最近，因為越來越多的同學會問到持續集成的問題，所以找了一些書和資料，學習了一下，然后問了自己一個問題：原來這就是持續集成??？
【新知】
這幾年持續集成的興起，并不是因為測試工程師越來越“懶”，而是隨著互聯網產品的運營模式和敏捷研發的廣泛應用，提升研發團隊持續交付能力的一個很重要的技術越來越受用，那就是持續集成。
我們先來看看引入持續集成的好處：
- 隨著項目越來越大，越來越復雜，每天各種各樣的開發工程師都在 check-in 代碼，如何能快速發現其中會導致構建失敗的錯誤代碼呢？-- 持續集成。
- 隨著研發速度越來越敏捷，測試工程師可能隨時都需要一個可測的版本去驗證 bug，做回歸測試，而不能等待所有的開發都提交了最新的、完整的代碼，再打一個沒問題的測試包，那怎么辦呢？-- 持續集成。
- 產品也需要經常拿一個可用的、最新的版本去體驗最新的功能，去驗收已經完成的需求，他可以找誰呢？-- 持續集成。
- 每日構建其實是一個重復性的活動，但又需要人每天去做這么一件事情，在它完成之前，大家都得等著，假如測試人員來的很早，那負責每日構建的人就要來的更早，怎樣才能既減少人力的重復勞動，又能提高效率呢？-- 持續集成
- 我們現在有很多自動化測試工具、靜態掃描工具和性能測試工具，那怎樣才能讓它們在有限的測試周期中發揮及時、有效的作用呢？-- 持續集成
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
