5.4　集成并最终发布

集成分支收到特性分支上的代码改动后，就自动触发集成分支上的流水线——构建、单元测试、代码扫描、生成Docker镜像、存入制品库、部署到集成测试环境、全量的自动化接口测试。集成分支上的流水线与特性分支上的流水线相比，现在能看到有两点不同：一是集成分支上是合并之后的代码，特性分支上是合并之前的代码，两者可能不完全一样。二是集成分支上的流水线多了几个步骤，其中把Docker镜像存入制品库是为了将来部署其他测试环境时复用，不用重复构建；而部署和自动化接口测试是为了进一步保证代码质量——在特性分支上没有对应的测试环境，做不了，而现在有条件了，那就多花几分钟执行它们吧！

如果流水线运行出现问题，那么就会自动通知小明，小明需要尽快修复问题。如果感觉修复有困难，那么就干脆先把这个特性分支的改动从集成分支摘除。

测试人员并不是等到本次计划发布的所有特性都合入集成分支后才开始测试的，而是只要有合入的特性，就会对其进行测试——主要通过GUI完成端到端的人工测试。在小明写代码期间，测试人员已经基本完成了测试分析和设计，所以此时测试进展得很快。测试人员会随时和小明交流测试遇到的问题，如果确实是程序有问题，则会创建缺陷记录给小明。小明在原特性分支上进行修改，修改后再次合入集成分支。

当本次计划发布的所有特性都合入集成分支后，就会从集成分支拉出一个发布分支——在这个发布分支上只做已完成特性的质量提升工作，不再加入新的特性。而此时集成分支可以持续接纳新的特性，以便实现下一个版本的发布。

发布分支上的测试，是在另一个更为正式的、更接近生产环境的测试环境中进行的。在这里，不仅测试人员要运行人工测试和自动化测试以进行最后的验证工作，产品负责人也会来查看新功能是否符合产品设计的本意。另外，如果有必要的话，还会做性能测试、安全测试等。

当确定都没问题后，就会把这个微服务的新版本对应的容器镜像部署到生产环境中，生成一个容器实例，然后引入1%的流量，看看这些用户会不会疯狂地给客服人员打电话……如果没有出现这种情况，那么就继续分批部署生成更多的容器实例并引流，同时密切观察相关运维指标，直到100%的流量都被引到新版本上，发布完成。

随后是善后工作：将发布分支合并到主干，因为主干代表着线上最新版本；也将发布分支合并到集成分支，于是下一个版本集成的内容就包含了本版本发布的内容。