项目发版更新流程规范v1 2

1、系 统 发 版 更 新 流 程 规 范 GTXD-XMGX-XTFB V1.2江苏国泰新点软件地址：江苏张家港市经济开发区()电话传真系统发版更新流程规范V1.2系 统 发 版 更 新 流 程 规 范 GTXD-XMGX-XTFB V1.2一、 目的 为规范系统发版更新流程，提升系统发版更新计划性，降低因频繁发版更新导致系统不稳定风险，特制定系统发版更新流程规范。 二、 适用范围 本规范适用于公司所有软件项目的发版更新管理。 三、 发版更新分类 发版更新包含代码更新、数据库更新、配置文件更

2、改。 四、 发版周期建议 系统发版遵行定期原则，一般项目上线前期，建议发版频率控制在按周发版，后续逐步扩大到按月发版，发版频率的有效控制一定程度上能反映出系统测试与验证的效果，提升系统质量。可以设想如果按周发版，系统测试与验证的时间往往都是有限的，虽能及时响应用户上线要求，但往往带来的副作用是系统极其不稳定，极大影响用户操作体验，频繁抱怨。 例如：某大型项目上线初期，问题较多，此时建议发版频率如下： 1、 BUG 发版，紧急 BUG（影响用户流程操作的）当天修复并发版，可以中午或下班后（非工作时间）；其余 BUG 根据重要程度、紧急程度一般控制在当周发版一次，以达到充分测试。 2、 需求发版，

3、根据需求提出时间先后，需求重要程度，客户领导关注等因素，梳理本次周期内需求发版，上线初期简单需求可以控制在按周发版，常规需求控制按两周发版，大型、复杂需求建议按三周到四周频率发版。 系 统 发 版 更 新 流 程 规 范 GTXD-XMGX-XTFB V1.2五、 发版更新实施过程 5.1. 发版前期准备工作 1. 汇总本次发版内容项目组根据要求定期上报本周期系统发版更新内容，并由专人进行汇总，形成发版2. 开发工作准备。 结合评审后形成的最终发版更新内容和时间，项目组提前邮件或通过系统（运维）更新申请单组内相关开发人员，要求各开发人员准备如下工作： 检查功能点对应代码，如有按分支版本开发，开

4、发负责人同步相关分支代码； 打更新包，如果是 Ecloud 模式，打镜像包； 准备数据库更新脚本，包括不限于：数据库字段新增/变更，菜单，工作流，代码项。 3.发版前 UAT软件的发版更新功能已经由开发、测试、实施人员在测试系统测试通过，且对于大型功能需通过用户 UAT 测试，并取得 UAT 通过报告（部分政府类型项目须签署系统更新申请表、上线申请单，特殊用户务必请客户在测试环境中试用并确认）。 4.发版前相关方若公司客服已介入项目的运维，且更新内容中包含与客服运维相关的功能，项目组在发版前应及时客服人员，必要时可提前对客服人员进行培训。 若系统更新内容中涉及网络、服务器策略等机房设备的调整，

5、项目组应提前相关部门做好系统发版更新配合工作。 5.2. 正式环境发版流程 本流程适用于正式环境的常规发版，以及计划内的临时发版。5.2.1.流程图 发 版前发布停机 项目组/甲方技术团队 业务批准 甲方业务负责人 发版检查（如有） 甲方技术团队 发版申请 项目组 系 统 发 版 更 新 流 程 规 范 GTXD-XMGX-XTFB V1.2执行发版动作发版中项目组技术及业务验证发版后邮件项目组项目组/甲方技术团队发版后发版结果检查项目组/甲方技术团队流程说明发版申请.正式发版申请（一般以邮件形式）工作由项目组发起，交由甲方技术团队进行发版审核（如有），大型发版申请提交时间不迟于

6、计划发版时间前三个工作日，常规发版申请不少于1 个工作日，临时/紧急发版不迟于计划发版时间前半个工作日。 发版申请单模板见下附录一，主要内容如下： 发版起始时间、发版持续时间段，待发版功能，发版风险评估及预防措施，发版期间业务用户是否可以正常使用系统等信息。 发版申请单中更加需要可包含下面的附加内容： 数据库调整说明（需进行数据库调整时提供）进行数据库调整的 SQL 语句及概要说明。配置文件调整说明（需进行配置文件调整时提供）待调整配置文件的路径名，及调整说明。发版检查（如有）2.发版检查工作一般指甲方技术团队负责执行，对发版申请提供的文档进行发版前检查，通过对发版检查结果和发版时间的综合判断

7、，从技术上判断是否执行发版，包括如下： 针对代码类发版，根据编码规范（拟定中）进行代码检查，要点如下： 命名及注释规范 HQL/SQL 检查 系 统 发 版 更 新 流 程 规 范 GTXD-XMGX-XTFB V1.2 对更新类语句，检查 where 条件是否过于宽泛，更新了不必要的数据。 对删除类语句，检查使用 delete 语句的必要性，原则上系统应使用逻辑删除，谨慎使用物理删除。 针对数据库调整，发版检查点如下： 对于新建表，参照编码规范中的数据表命名规范进行检查。 对于新增字段，检查是否有对历史数据的处理方案（默认值或其他）。 对于修改字段长度，原则上不允许缩减字段长度。 不允许删除

8、表和字段。 针对其它数据对象（视图、索引等）的删除，检查发版申请提供的说明文档中的删除风险分析及风险应对措施。 对于数据表记录的更新或删除，检查原因说明及风险应对措施。 对于配置文件调整 检查配置文件调整说明是否准确有效，风险说明及风险应对措施是否合理有效。 业务批准3.由甲方业务负责人执行对本次功能发版进行业务审批。注：一般大型项目，甲方内部对功能发版都有严格管控，故对发版业务内容需提前报备至甲方业务经办人处进行审批，已达到发版管控。 发布停机4.针对影响最终用户（如交易系统中投标人、招标人等）在发版期间内系统正常使用的，项目组/甲方技术团队在执行发版前，需发布系统停机，已达到告知用户，降低

9、用户使用影响。 停机发布原则：所有项目原则在执行大型发版、常规周期性发版前必须要执行停机。紧急发版在能做到服务不中断的前提下可以不发布系统停机（但必须要和甲方用户提前申请并告知清楚）。 系统停机一般可通过外部邮件、网站公告、系统公告、QQ 群以及系统登录消息提醒等方式执行。具体停机模板参考附录二。 执行发版动作5.由项目组执行发版动作，根据发版内容进行代码发布、数据库调整和配置文件调整。 根据发版需要，由项目组执行服务器节点重启操作使发版生效。对于多节点应用，应该采取节点逐一重启的方法，以保障系统的不中断运行。 系 统 发 版 更 新 流 程 规 范 GTXD-XMGX-XTFB V1.2节点

10、重启完成后，应根据实际需要，可进行应用服务器缓存清理动作。 注意事项： 系统更新前务必“先备份程序及数据库、后更新、再验证”； 系统更新统一由入职二年以上工作人员（含开发及实施团队）方可操作； 对于入职未满二年人员，更新必须在小组负责人监督下完成；如确实需要更新的，部门经理应对其进行单独培训和强调更新规范和注意事项； 系统的每次更新必须由专人负责，严格控务器远程和数据库操作面权限； 工作时间的更新，必须经甲方及部门经理认可后，方可操作；非工作时间由入职两年以上员工或小组负责人自行判断；（综合考虑是否有竞价项目、评标项目是否正在进行） 以上更新仍必须告知项目现场人员及项目经理，由项目现场人员评估

11、（这里指已经识别无风险后）是否可以更新。这里描述的更新，包括但不仅限于：系统更新、服务器重启、IIS 回收、服务重启、CodeFile 临时处理； 对于工作时间的定义：上午 8 点-12：00；下午 13:30-18:00 ，对于后期私自更新造成严重后果，一律受连带责任。 技术及业务验证6.发版完成后，由项目组进行必要的技术和业务验证，降低因发版造成的系统故障风险。 注意事项： 系统功能验证原则不可在正式系统走测试数据，与甲方提前沟通约定的除外； 功能更新后，不要遗漏相关的菜单配置、权限划分、参数配置； 涉及到 CA 驱动、投标文件制作工具等更新时，功能更新后，需要在网站、登录页面及时更新安装包。 发版结果核查7.由项目组/甲方技术团队对发版结果进行核查，确保按照发版申请进行了发版动作。 发版后邮件8.完成技术及业务验证后，由项目组/甲方技术团队发送发版完成邮件给系统用户，告知本次发版功能，以便用户了解功能操作变化。 5.3. 紧急情况下发版流程 1.项目组运维过程中发现问题，反馈开发排查； 系 统 发 版 更 新 流 程 规 范 GTXD-XMGX-XTFB V1.22.开发排查后判断因系统发版更新所导致，同时进行测试系统问题修复； 3.若产生的问题必须更新系统才可解决，项目组及时反馈至项目经理； 4.项目经理及时与客户负责