5.4　集成并最終發布

集成分支收到特性分支上的代碼改動后，就自動觸發集成分支上的流水線——構建、單元測試、代碼掃描、生成Docker鏡像、存入制品庫、部署到集成測試環境、全量的自動化接口測試。集成分支上的流水線與特性分支上的流水線相比，現在能看到有兩點不同：一是集成分支上是合并之后的代碼，特性分支上是合并之前的代碼，兩者可能不完全一樣。二是集成分支上的流水線多了幾個步驟，其中把Docker鏡像存入制品庫是為了將來部署其他測試環境時復用，不用重復構建；而部署和自動化接口測試是為了進一步保證代碼質量——在特性分支上沒有對應的測試環境，做不了，而現在有條件了，那就多花幾分鐘執行它們吧！

如果流水線運行出現問題，那么就會自動通知小明，小明需要盡快修復問題。如果感覺修復有困難，那么就干脆先把這個特性分支的改動從集成分支摘除。

測試人員并不是等到本次計劃發布的所有特性都合入集成分支后才開始測試的，而是只要有合入的特性，就會對其進行測試——主要通過GUI完成端到端的人工測試。在小明寫代碼期間，測試人員已經基本完成了測試分析和設計，所以此時測試進展得很快。測試人員會隨時和小明交流測試遇到的問題，如果確實是程序有問題，則會創建缺陷記錄給小明。小明在原特性分支上進行修改，修改后再次合入集成分支。

當本次計劃發布的所有特性都合入集成分支后，就會從集成分支拉出一個發布分支——在這個發布分支上只做已完成特性的質量提升工作，不再加入新的特性。而此時集成分支可以持續接納新的特性，以便實現下一個版本的發布。

發布分支上的測試，是在另一個更為正式的、更接近生產環境的測試環境中進行的。在這里，不僅測試人員要運行人工測試和自動化測試以進行最后的驗證工作，產品負責人也會來查看新功能是否符合產品設計的本意。另外，如果有必要的話，還會做性能測試、安全測試等。

當確定都沒問題后，就會把這個微服務的新版本對應的容器鏡像部署到生產環境中，生成一個容器實例，然后引入1%的流量，看看這些用戶會不會瘋狂地給客服人員打電話……如果沒有出現這種情況，那么就繼續分批部署生成更多的容器實例并引流，同時密切觀察相關運維指標，直到100%的流量都被引到新版本上，發布完成。

隨后是善后工作：將發布分支合并到主干，因為主干代表著線上最新版本；也將發布分支合并到集成分支，于是下一個版本集成的內容就包含了本版本發布的內容。