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

流水线打包部署包括两个方面，一个是新功能提交或新bug解决，只有这种情况才需要人工验证。因此一次流水线执行如果没有新需求或Bug状态变化，那么应该直接跳过人工验证节点并关闭。反之，则应该跳转到待人工验证环节。
需求和缺陷的管理
注意新需求和新缺陷都应该提交，都有状态，需求细分到具体的需求功能点，同时测试人员提交的缺陷应该对应到具体的需求功能点上面。一个需求开发完成后，需求本身也到待验证状态，但是一个待验证的需求是否能够关闭则必须是该需求下面所有的bug都解决完成后才能够关闭。
需求和缺陷状态的变化
开发人员首先是将需求或缺陷完成，并在本机进行自测通过，然后将代码check in到配置管理库。同时手工将需求或缺陷状态处理到待部署状态。
在流水线启动后，如果整个构建打包和部署成功，则在成功完成应用部署后，将待部署状态的需求或bug转到待验证状态。在部署完成后测试人员可以看到待验证的bug或需求，那么他进入当前的测试环境一定是最新的可以进行缺陷验证的环境。
应用部署和环境迁移
文章插图
实际上我一直在思考如何理清这两者的关系，包括在流水线节点设计的时候是同种类型的一个节点还是不同的两个节点？应用来说是直接将编译打包后的镜像执行进行部署，前面有编译构建操作；而对于环境迁移来说则是直接从制品库里面使用已有镜像进行环境部署。
流水线模板和流水线实例应该是两个不同的概念，一个流水线模板每次运行都会产生一个实例，而每次实例都会形成一次构建版本号。
即每次打包后形成的镜像入库也会附带上这么一个流水线实例号。那么我们的应用部署操作相对就简单了，即对于应用部署活动节点编排在流水线上面，作用是进行应用部署，但是本质是从制品库拿到对应镜像去部署。如何拿到对应镜像，基于流水线实例号就可以很好的进行对接上。
在环境迁移中，我们设置两个环境，一个SIT环境供内部测试人员测试，一个UAT环境供客户方进行UAT测试，那么在SIT测试完成后可以将SIT环境的镜像包迁移到UAT环境进行部署。
注意并不是每一次流水线作业都涉及到环境迁移操作，而实际上需要测试人员去判断当前的测试版本是否需要迁移到UAT环境去供用户测试。同时测试人员在当前测试问题全部修复并关闭后可以对当前版本进行配置基线操作。
其次，对于用户测试提交的问题一般并不会在我们自己的缺陷管理系统进行Bug记录，因此用户反馈问题给测试人员，测试人员帮忙录入到缺陷管理系统，同时缺陷修改完成后测试先要验证没有问题，再通知用户进行验证，只有用户验证通过后缺陷才能够最终关闭。
同时基于前面谈到的，当一个传统的单体应用拆分为多个微服务后，由于我们本身向客户交付的还是单体应用本身，因此最佳的设计方式还是启用产品和项目两级流水线设计方式，将人工测试验证和环境迁移操作配置在产品级流水线上面。
【对DevOps流水线设计的优化和改进实践】头条号：@人月聊IT 分享IT架构和中台规划， SOA ，微服务，云原生解决方案