《业务系统发布规范v1.0》由会员分享，可在线阅读，更多相关《业务系统发布规范v1.0（22页珍藏版）》请在金锄头文库上搜索。
1、业务系统发布规范业务系统发布规范 V 1.0 2015.09.15 目 录 一、四种发布流程详述 常规发布 大版本发布 Quick Fix HotFix 二、版本回退处理 三、基础架构变更流程 HotFix 常规发布 大版本发布 适用范围 常规发布：日常小需求发布 大版本发布：大项目发布 Quickfix：生产环境中的Bug Fix Hotfix：导致在线交易无法进行的Bug 发布频次 大版本发布：专门排期，大致四周一次 常规发布：大致每周一次，除大版本发 布日前一周 Quickfix：最多每天一次 Hotfix：随时 发布流程遵循原则： 1、事前充分准备 2、事中快速响应 3、事后深度分析
2、影 响 度紧急度 零界点 QuickFix 一、四种发布流程概况 1、大版本发布适用范围及参与人员 适用范围：大项目的发布、经全部测试流程、达到上线标准 参与人员 项目经理 架构师 开发，测试 运维人员 业务人员 技术管理组 1、大版本发布基本流程 周二封版 测试周期：以三周为基准， 根据项目难易程度上下浮动 完成测试，按准出标准验收 SIT准出标准 测试案例通过率100% L1、L2缺陷留存数为0 L3、L4留存缺陷必须有对应的变通解决方案，切必须经过业务评估不能影响生产环境运营 验 收 成 功 实 施 部 署测试验收阶段 发布日前两周 （周四） 召开技术管理 组会 确 认 最 终 发 布
3、需 求管理层评审 生产环境验证 由PM确认生产环境验证方案，由业务或者运营部门执行验证过程 部署后 生产环境验证 发布时间点为9:30点，9点之前达到发布要求的可以发布 周三(根据实际发布行事历) 应用运维部署到生产环境 实施部署 验 证 生 产 环 境发布日前1个月 提交发布计划 需 求 冻 结需求冻结 eg： 若大版本发布日 为2月15日，提 交需求截止日为 1月15日 附表：常规及大版本发布日计划 20152015 Release CalendarRelease Calendar 2015/9/16 13:44 JANUARY FEBRUARY MARCH S M T W T F S S
4、 M T W T F S S M T W T F S 1 2 3 1 2 3 4 5 6 7 1 2 3 4 5 6 7 4 5 6 7 8 9 10 8 9 10 11 12 13 14 8 9 10 11 12 13 14 11 12 13 14 15 16 17 15 16 17 18 19 20 21 15 16 17 18 19 20 21 18 19 20 21 22 23 24 22 23 24 25 26 27 28 22 23 24 25 26 27 28 25 26 27 28 29 30 31 29 30 31 APRIL MAY JUNE S M T W T F S S
5、 M T W T F S S M T W T F S 1 2 3 4 1 2 1 2 3 4 5 6 5 6 7 8 9 10 11 3 4 5 6 7 8 9 7 8 9 10 11 12 13 12 13 14 15 16 17 18 10 11 12 13 14 15 16 14 15 16 17 18 19 20 19 20 21 22 23 24 25 17 18 19 20 21 22 23 21 22 23 24 25 26 27 26 27 28 29 30 24 25 26 27 28 29 30 28 29 30 31 JULY AUGUST SEPTEMBER S M T
6、 W T F S S M T W T F S S M T W T F S 1 2 3 4 1 1 2 3 4 5 5 6 7 8 9 10 11 2 3 4 5 6 7 8 6 7 8 9 10 11 12 12 13 14 15 16 17 18 9 10 11 12 13 14 15 13 14 15 16 17 18 19 19 20 21 22 23 24 25 16 17 18 19 20 21 22 20 21 22 23 24 25 26 26 27 28 29 30 31 23 24 25 26 27 28 29 27 28 29 30 30 OCTOBER NOVEMBER
7、DECEMBER S M T W T F S S M T W T F S S M T W T F S 1 2 3 1 2 3 4 5 6 7 1 2 3 4 5 4 5 6 7 8 9 10 8 9 10 11 12 13 14 6 7 8 9 10 11 12 11 12 13 14 15 16 17 15 16 17 18 19 20 21 13 14 15 16 17 18 19 18 19 20 21 22 23 24 22 23 24 25 26 27 28 20 21 22 23 24 25 26 25 26 27 28 29 30 31 29 30 29 27 28 29 30
8、31 2、常规发布适用范围及参与人员 适用范围 适用于日常发布 参与人员 项目的发布 日常小需求 项目的Bug fix 项目经理 架构师 开发，测试 运维人员 业务人员 技术管理组 2、常规发布基本流程 周五下班前 提交发布计划 需 求 冻 结需求冻结 周一 召开技术管理 组会 确 认 最 终 发 布 需 求管理层评审 生产环境验证 小需求和Bug fix 由子系统负责人确 认验证方案，由测 试或者开发人员、 业务方成立验证小 组，共同执行验证 过程 部署后 生产环境验证 除大版本发布日前一个周四外，发布时间点为9:30点，9点之前达到发布要求的可以发布 周四 应用运维部署到生产环境 实施部署
9、 验 证 生 产 环 境验 收 成 功 实 施 部 署周二、三 完成测试，按准出标准验收 SIT准出标准 测试案例通过率100% L1、L2缺陷留存数为0 L3、L4留存缺陷必须有对应的变通解决方案，切必须经过业务评估不能影响生产环境运营 测试验收阶段 2、常规及大版本发布标准上线流程中的“特批” 标准上线流程中的“特批” 未达到准出标准，但由于业务需要，还是要上线 未列在发布计划中的计划外发布需求 需相关部门长Email 批准： 收件人包括：业务部门长，开发人部门长，测试部门长， 抄送人包括：业务人员，业务部门长，开发人员，开发人直属领导，测试人员，测试人直属领导，运维人员，运维人员直属领导
10、 邮件内容：缺陷描述、上线特批原因、部署方法、回滚方案、要求实施时间 紧急情况下，可先由部门长口头批准，事后补email留档 邮件标题：【特批】关于常规发布中XXX的特批申请 邮件正文：关于常规发布中XXX的特批申请，具体内容如下： 1、【缺陷描述】： 2、【上线特批原因】： 3、【部署方法】： 4、【回滚方案】： 5、【要求实施时间】： 2、 常规发布中“特批”邮件模板 2、常规发布标准项目各角色职责说明 PM 子系统负责人 确认提测时间、计划发布时间、是否将数据库变更、配置变更等更新到部署说明文档，确认可能的影响范围，即是否会对其他模块产生影响 测试人员 提供测试报告， 功能说明和测试实
11、际内容一致 运维人员 确认部署说明文档 是否提交，数据库变更 或者架构变更是否已批 准，并给出上线预计时 间 10点之前 邮件至部门长 需求冻结 11点之前提测 测试阶段 15点之前完成测试 达 到 准 出 标 准Email申请 1、收件人包括：业务部门长，开发人部门长，测试部门 长 2、抄送人包括：业务人员，业务部门长，开发人员，开 发人直属领导，测试人员，测试人直属领导，运维人员， 运维人员直属领导 3、邮件内容： Bug编号&描述、Bug修复人员&测试人 员、上线原因、部署方法、回滚方案、要求实施时间 备注： 紧急情况下，可先由部门长口头批准，事后补email留档 3、Quick Fix
12、适用范围及基本流程 适用范围 生产环境的紧急Bug fix，不允许增加任何新功能 邮件标题：【Quick Fix 】关于XXX的Quick Fix的申请 邮件正文：关于XXX的Quick Fix的申请，具体内容如下： 1、【Bug编号&描述】： - Bug编码为XXXXXXXXXX - Bug具体描述如下 2、【Bug修复人员&测试人员】： 3、【上线原因】 4、【部署方法】： 5、【回滚方案】： 6、【要求实施时间】： 3、 Quick Fix邮件申请模板 随时 需求冻结 4、Hot Fix适用范围及基本流程 适用范围 针对造成在线业务无法进行或其他有重大影响的Bug，进行紧急修复的流程 E
13、mail申请 1、收件人包括：业务部门长，开发人部门长，测试部 门长 2、抄送人包括：业务人员，业务部门长，开发人员， 开发人直属领导，测试人员，测试人直属领导，运维 人员，运维人员直属领导 3、邮件内容包括：Bug编号&描述、Bug修复人员& 测试人员、部署方法、回滚方案、要求实施时间（数 据的变更以bug的形式上报） 事后分析 事后须业务、产品、开发、 测试、运维等各部门做深 度分析报告（DDA）并由 发起人牵头汇总，发送， 各相关中心总，严重的须 直接发送总经办 备注：三天内上交DDA 邮件标题：【Hotfix 】关于XXX的Hotfix的申请 邮件正文：关于XXX的Hotfix的申请，
14、具体内容如下： 1、【Bug编号&描述】： - Bug编码为XXXXXXXXXX - Bug具体描述如下 2、【Bug修复人员&测试人员】： 3、【部署方法】： 4、【回滚方案】： 5、【要求实施时间】： 4、 Hotfix邮件申请模板 适用范围 -生产环境的数据库变更（与代码无关的单独的数据库变更） Email申请 1、收件人包括：申请人所在的系统负责人 2、抄送人包括：业务人员，业务部门长，开发人员， 开发人直属领导，测试人员，测试人直属领导，运维 人员，运维人员直属领导、运维部门长、业务部门长、 测试部门长，数据分析部门长 3、邮件内容包括：用于数据库运行脚本的用户名、运 行脚本的顺序、
15、变更的数据量、修改前表内总数据量、 用于备份数据的脚本、需要执行脚本的内容、回退脚 本、变更后性能影响、连带系统、风险评估、执行时 间、创建 的L1 Bug 用来跟踪此事件、事后总结 DDA 负责人 附：数据库变更流程操作 选择流程 对应系统开发人员根 据实际需求发起数据 库变更申请 事后 所有数据库的变更执行后 需要 1、Resolve L1 bug, 给出 实际执行时间和结果，附 上邮件。 2、做出DDA ： 给出修改 生产数据的原因是设计还 是实现的缺陷，怎样改进， 怎样避免？ 什么时间点可 以实现改进？（三天内完 成DDA） 邮件标题：【生产环境的数据库变更】关于XXX数据库变更的申请 邮件正文：关于XXX的数据库变更的申请，具体内容如下： 1. 【修改原因】：（申请人提供） 2. 【业务风险评估】：（申请人提供） 3. 【目标执行时间】：（申请人提供） 4. 【用于数据库运行脚本的用户名】：（开发提供） 5. 【预估变更的数据量】：（开发
