执行阶段
部署发布阶段，由测试人员、项目经理、技术负责人、运维人员执行。
执行人
业务组技术负责人与测试人员、项目经理、运维人员，协调执行落地。
规范内容
一、发版流程
image.png
二、发版评审会
1、上线评审采用开【发版评审会】形式进行，由项目经理发起，项目管理、产品、设计、开发、测试、运维等相关部门人员参加。
2、发版评审会需确定事项如下：
-
发哪些服务，包括前、后端程序。
-
测试环境验证情况，是否封版。
-
发版时间安排
-
各服务的代码分支、版本号
-
代码是否合并到正确分支，是否在测试环境 default 特性环境验证通过
-
收集并确认相关的发版说明文件是否完整无遗漏
-
确定此次发版数据库变更是否影响大数据平台，如有影响则需要协调大数据组。
-
确定此次发版是否需要停服，如需停服则协调运营相关部门发系统更新公告。
3、发版评审会结束后，由业务组在 TAPD 填写发布评审，流转至运维，运维组将开始着手进行相关准备、执行发版动作。
三、发版说明相关文件规范
- 所有提交给运维的发版说明相关文件，以附件形式在放在「评审依据」项中，最多 5 个附件。
- 文件若打包，请按项目组打包，例如 Java 的打成一个，PHP/NODE 类的打成一个。
- 发版微服务说明总表格文件，固定名称：``{业务组名称}
_YYYYMMDD_发版.xlsx - 数据库变更相关文件，取名为：
db_update_{服务名称、业务组名称}.sql - 配置文件变更相关说明，取名为：
config_update_{服务名称、业务组名称}.txt - 其他说明文件，取名为：
release_note_{服务名称、业务组名称}.txt
四、TAPD 发布评审单填写说明
1、填写时机：测试人员在测试环境对需要发版的所有服务均验证无问题了，项目组内部的产品（项目）、技术负责人确认可以发布，同时开发人员已正确合并代码后，再进行填写。
2、流转机制：【发布评审单】由项目组技术负责人安排组内人员填写，然后由技术负责人进行在线评审，确认发布到灰度，灰度验证通过后再由技术负责人签发【发布评审单】 发布到生产环境，运维发布完后内部信息同步，项目组内部的测试人员（或测试负责人）线上验证无问题后确认发布结果状态。
3、字段填写：
1）需要发版的服务名、版本号（测试环境构建版本号）、负责人，以表格形式填写，填写在【备注】字段；
2）初始化【发布评审单】时，【签发人】字段填写技术负责人，【发布确认人】字段填写业务组测试人员或测试组负责人。
3）评审活动列表中的【业务线负责人签核】字段填写技术负责人，【运维人员确认灰度部署】字段填写运维人员或负责人。
4）业务组技术负责人签核发布评审活动时，可在【通知相关人】字段中填写相关运维人员或负责人、测试人员、产品（项目）负责人、产研中心CTO。
5）运维人员或负责人更新灰度部署状态时，可在【通知相关人】字段中填写相关的测试人员、开发人员、业务组技术负责人、产品（项目）负责人。
6）【发版时间安排】字段，视不同场景按需填写：A 需具体时间发布的，填写具体时间，B 停服发布的，可以不填写具体时间，C 需要立即发布的，请填写即时。
7）正常发版流程、紧急发版流程里的所需填写的字段是不同的，请注意区别。
示例
下图所示为发版评审会结束填写的「发布评审」内容。
image.png
五、灰度发布文明规约
为减少对生产环境真实用户流量的影响，避免出现生产故障十万火急的线上修复，我们在进行灰度发布过程中，需要遵从以下原则：
1、数据库的变更如需修改字段、添加字段、修改索引、添加索引，需评估被修改的表当前的数据量，评估该 SQL 语句的执行时间，数据量超过100万条记录，不可白天高峰流量期间执行；
2、生产发布不建议删除字段的数据库变更，【发布评审单】的各评审、确认人员，都应该仔细查看发版说明，共同确保因为数据库变更导致生产故障。如需删除，则需要各业务组技术负责人同步确认后，再安排闲时由运维人员执行删除；
3、数据库变更有添加新字段的，该字段必须有缺省值；
4、数据库变更，必须评估确认兼容当前生产环境的程序包；
5、目前前端H5未提供灰度发布策略，前端H5发布前需要先确保后台程序已完成灰度，确认灰度验证通过；
6、灰度发布现在是试运行阶段，灰度转生产，通用时间为晚上 7 点之后，不要在白天高峰流量期间进行；
7、内部测试企业可长期保留在灰度企业列表中，真实用户企业，应在灰度转生产后删除，并更新网关的配置；
8、将某家真实用户企业加入灰度企业列表前，业务线的相关负责人应跨部门协调，知会客户，确保客户知晓并同意参与灰度；
9、真实用户企业参与灰度，且灰度时间较长时，应同步信息到客户服务相关部门。
网友评论