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

简单来说，测试人员发现build1.0.0001版本4个bug并提交，那么在下次自动化构建完成并单元测试通过后，测试人员能够很清楚的看到哪些Bug已经修改并可以在新构建的版本进行验证。只有这样才能够形成闭环，整个流水线作业才能够更好的发挥协同作用。
两级流水线设计在进行微服务架构设计和开发的时候可以看到，原来的单体应用已经拆分为多个微服务。比如一个财务报账应用，我们拆分为报销管理，系统管理，流程引擎，数据管理，接口管理，门户管理六个微服务模块。
那么整个报账应用实际上就是产品-》微服务的两级架构模式。
在整个DevOps支撑平台基础数据配置的时候，我们首先需要支持将报账应用配置为独立的产品，并在该产品下配置6个独立的微服务项目。
我们最终向客户交付的是整个报账应用产品，但是对于开发和持续集成的过程则是按照微服务项目的粒度进行管理。特别是在后续运维变更的时候，如果仅仅是报销管理模块发生了变更，我们希望的仅仅是对报销模块流水线进行运行和持续集成，而不是所有的微服务模块都进行重新构建。
文章插图
基于两级流水线设计，我们希望达到的效果就是：
我们不用去关心产品变更的时候究竟变更了哪些微服务模块，即一次变更我们直接启动产品流水线。产品流水线启动后自动检查哪些微服务发生变更，如果发生变更则出现持续集成操作，如果没有变更直接调整到End完成节点。
在所有微服务单个流水线执行完成后，我们聚合到产品流水线进行人工测试和验证，没有问题后我们可以进一步进行打标签操作，或触发环境迁移操作。
注意环境迁移我们可以根据本次变更版本号或根据我们手工打的标签号进行，同时环境迁移操作本身不再涉及到编译构建和打包操作，因此环境迁移应该配置在产品级流水线上进行。
如果从SIT环境迁移到UAT环境后测试不通过，测试出了相应的Bug ，这个时候产品流水线退回到开始节点，同时开发人员在修改完成Bug后，同样系统自动判断哪些微服务模块代码出现变更并自动触发构建打包操作，直至所有的Bug修改完成并验证通过。
注意，在传统的方式下，我们将环境迁移操作配置到微服务项目流水线上面，这种方式本身存在问题。即我们最终测试和发布的是产品，一个产品的变更往往涉及到多个微服务模块的修改，如果将环境迁移配置在微服务上，那么将大量增加人工操作去进行环境迁移和多微服务间版本同步操作，这个显然是增加了开发人员工作量。
通过流水线实现研发过程管理和持续集成协同
文章插图
在DevOps实践中，一定要解决好的就是开发和测试的协同，开发测试和工程运维的协同。因此对于研发项目过程管理工具， DevOps支撑工具本身要紧密集成才能够更好的支持整个协同过程。
虽然敏捷方法论强调面对面的沟通，但是在整个持续交付过程中要减少各种无谓的沟通，通过工具进行自动化协同。类似测试不清楚开发的功能是否完成了，是否可以测试了，是否部署到SIT环境了， Bug是否修改好可以重新验证了等等问题，都应该在工具层面进行解决。

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

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

基于收集到的用户需求整理后形成软件需求，进行版本规划，纳入需求和Bug
规划一个新的项目版本号，后续的项目需求，任务，缺陷管理等也都基于该版本号进行
- 上一页
- 1
- 2
- 3
- 4
- 5
- 下一页