记环境部署中部署文档及版本更新回归测试说明

项目背景：机器人的调度平台

迭代背景：敏捷开发

记录方向：环境部署过程的部署文档及版本更新回归测试

记录时间：20211009

===============================================

项目团队小，许多东西不够规范，已经多次提及测试的准入准出规则，但是收效甚微，环境部署问题、提测冒烟测试不通过等问题重复出现，所以就抽时间写了相关的准入准出规则，这儿记录一下环境部署及

提测相关的问题。

 

背景:微服务容器化部署、数据库服务未为单独的mysql集群，主从架构；环境分为dev、sit、uat、prod四个环境，前三个环境为公司内部的云环境（已经实现CICD），prod部署在阿里云上（为了减少部署、运维成本）。

问题点：每次更新版本到sit环境经常遗漏更新数据库脚本，或者漏更某依赖服务，导致版本更新的回归测试不通过或者冒烟测试不通过；

问题分析：1、dev、sit、uat实现了CICD，代码合并后直接通过pipeline插件直接就部署到相关的环境中，没有对CICD部分中权限控制及审核机制；

　　　　　2、针对特定的环境没有相关的部署说明文档，版本更新导致应该更新哪些部分程序或者数据库或者定时任务等；

　　　　    3、特定环境的版本更新版本不匹配，部分服务更新，部分服务未更新；

措施：1、针对sit、uat环境的CI未做权限控制，项目组的开发人员都进行合并，针对CD只有特定人员有CD权限，并伴有审核人员，如果版本更新出现问题，审核人员有连带责任，审核人员不是一个虚设的角色，必须根据相关的部署文档文档检查是否已经更新完整；PROD的CD过程只有一个特定人员有权限，所有其他人员连相关地址都不清楚，所有相关的数据库都无写权限，部分人员有读权限，防止相关开发人员在生产环境的数据库中进行相关得写炒作；

　　　2、每次CD过程必须提供部署说明文档给审核人员，说明本次更新涉及到的服务、更新内容、其他更新（如数据库、定时任务、菜单，新增第三方工具等）、大致影响范围、拉取的分支、更新时间、更新人员等信息，保证每次版本更新都是按照文档进行更新的，避免出现漏更等低级错误；部署说明明档也可以作为提测文档提供给测试人员。相关的文档就不贴出来了；

　　   3、版本更新的回归测试可以根据版本库里面的基础冒烟测试用例来检查版本是否正确；采用自动化接口测试，根据触发规则在版本更新后触发接口测试用例的执行，执行完成后发送邮件给相关人员。