对DevOps流水线设计的优化和改进实践( 三 ) 对于DevOps过程支撑平台

在所有微服务单个流水线执行完成后，我们聚合到产品流水线进行人工测试和验证，没有问题后我们可以进一步进行打标签操作，或触发环境迁移操作。
注意环境迁移我们可以根据本次变更版本号或根据我们手工打的标签号进行，同时环境迁移操作本身不再涉及到编译构建和打包操作，因此环境迁移应该配置在产品级流水线上进行。
如果从SIT环境迁移到UAT环境后测试不通过，测试出了相应的Bug ，这个时候产品流水线退回到开始节点，同时开发人员在修改完成Bug后，同样系统自动判断哪些微服务模块代码出现变更并自动触发构建打包操作，直至所有的Bug修改完成并验证通过。
注意，在传统的方式下，我们将环境迁移操作配置到微服务项目流水线上面，这种方式本身存在问题。即我们最终测试和发布的是产品，一个产品的变更往往涉及到多个微服务模块的修改，如果将环境迁移配置在微服务上，那么将大量增加人工操作去进行环境迁移和多微服务间版本同步操作，这个显然是增加了开发人员工作量。
通过流水线实现研发过程管理和持续集成协同
文章插图
在DevOps实践中，一定要解决好的就是开发和测试的协同，开发测试和工程运维的协同。因此对于研发项目过程管理工具， DevOps支撑工具本身要紧密集成才能够更好的支持整个协同过程。
虽然敏捷方法论强调面对面的沟通，但是在整个持续交付过程中要减少各种无谓的沟通，通过工具进行自动化协同。类似测试不清楚开发的功能是否完成了，是否可以测试了，是否部署到SIT环境了， Bug是否修改好可以重新验证了等等问题，都应该在工具层面进行解决。

开发和测试协同：重点解决版本多次编译构建持续集成和测试验证过程协同
开发和运维协同：重点解决测试完成版本发布后，工程运维进行版本提取和部署的协同

我们重新思考下整个持续交付的过程

基于收集到的用户需求整理后形成软件需求，进行版本规划，纳入需求和Bug
规划一个新的项目版本号，后续的项目需求，任务，缺陷管理等也都基于该版本号进行
开发构建一个流水线，完成编译，构建，代码检查，发布，自动化单元测试，对应Dev环境
开发应该在对发布到Dev环境的功能再做一下自测（手工节点）
开发在自测没有问题的时候，应该自动的将该部署包迁移部署到SIT环境
开发提交一个测试申请单，关联可以进行测试的需求或Bug
测试人员只需关系待测试验证的需求，在SIT环境的版本一定是部署好可验证的版本
测试对需求进行验证，并提交Bug ，测试人员修改Bug并触发流水线重新构建
测试在所有缺陷全部验证通过后，确认集成测试通过环境，版本自动迁移到UAT环境
在UAT环境的验收测试同样的道理
在UAT环境所有问题也验证关闭后，进入到正式发布生产环境。

流水线设计属于持续交付过程域中的一个关键内容，其核心还是为了持续集成服务。简单来说就是流水线作业解决自动化的持续集成问题，那么持续集成本身又包括哪些关键内容？
即我们常说的自动化编译构建，自动化部署，自动化测试。而在转到和容器技术结合后可以看到在编译构建完成后自动化部署进行了拆分，即部署动作变化为了首先是自动化的打包即制作容器镜像，然后才是自动化部署，部署部署基于部署包的，而是基于制品库中的容器镜像的。
可以看到，在DevOps中的流水线设计更多的是解决开发人员的自动化问题，即开发只需要check in自测通过的代码到配置管理库，那么后续的所有事情都自动化完成，最终部署到测试环境供测试人员测试。
开发人员不用关心编译构建过程，不用关心测试服务器包括测试环境数据库，中间件的安装部署等一系列的问题。同时由于一系列的自动化操作，也让代码从检入到交付测试的周期缩短了，在周期缩短后交付频度也可以进一步提升以加快迭代速度。
对于DevOps支撑平台我们一直在谈流水线自动化设计，但是更应该反过来谈持续集成方法论和最佳实践，因为流水线设计仅仅是为持续集成和持续交付服务的工具链而已。其次，对于当前流水线设计，更多是从技术层面开发人员自动化在谈，但是却少考虑研发管理开发和测试过程协同问题。