补丁包管理规定
集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#
补丁包管理办法
名词术语
1、 补丁包：由公司统一规划版本的补丁程序。
2、 临时补丁包：由紧急任务引起，临时发布的补丁程序。
角色和职责
1、 产品经理：
? 负责版本规划、版本范围变更，制定总体目标和计划。 2、 版本经理：
? 负责补丁包的开发、测试、补丁包生成等工作，制订详细的工作分解计划。 3、 发布管理员：
? 负责补丁包开发过程中发布测试版本。
补丁包命名
1、 基线版本命名格式为： 项目名称V版本号，例： 2、 补丁包命名格式为： 项目名称V版本号SP编号，例： 3、 临时补丁包命名格式为：
项目名称V版本号SP编号_L编号，例：
整体流程 版本规划
1、 产品经理（指开发部门经理）收集需求和缺陷，并组织对需求
和缺陷的评审，形成评审结果，具体分为： （1）接收并指定实现版本； （2）拒绝同时给出拒绝原因；
2、 产品经理根据公司、客户等多方面的要求，制定每个版本的开
发周期，并指定版本经理。版本经理根据每个版本的开发范围合理安排开发、测试计划，如有变化，请及时和产品经理沟通以便进行版本开发范围或计划的变更。
补丁的开发、测试
1、 补丁包
（1） 将补丁包开发作为一个项目，由产品经理指定版本经理负责补丁
包的开发、测试、补丁包生成和申请发布工作。
（2） 补丁包的开发、测试、补丁包生成和申请发布工作由版本经理负
责组织制定详细的工作分解计划。
（3） 补丁包的测试版本发布由版本经理指定版本管理员负责，发布测
试版本时要合并与上一个补丁包之间的所有临时补丁。
（4） 测试完成后版本经理组织将分支合并到主干，解决冲突后生成补
丁包。
（5） 补丁包采用兼容性补丁模式，即：补丁包均是基于trunk的增量
包，后面的补丁兼容前面的补丁。（与兼容性补丁相对应的就是独立补丁，补丁包均是基于trunk的增量包，后面的补丁不兼容前面的补丁，各个补丁间是独立的；）
注：制作增量补丁包的方法见附件2 2、 临时补丁包
（1） 由开发部经理指定人员负责开发。 （2） 开发完成后提交质量部测试。 （3） 测试通过后发布临时补丁包。
Svn目录结构和合并说明 1）svn目录结构说明
（1） 项目过程资料由code、database和doc三部分组成。其中code
用于存放项目代码和发布的程序；database用于存放数据库备份；doc用于存放项目过程中产生的文档。 （2） code又分为Trunk、branches和tags。
? trunk为主干，用于存放稳定版本的源程序、合并分支和发布补丁包。
? branches为分支，用于开发。
? tags分为release、test、sourcefile，其中release用于存放批准发布的补丁包（可执行文件）；test用于存放测试版本；sourcefile用于存放全量的源文件。
2）版本合并
（1） 上图中1、2表示从做分支到branches进行开发；
（2） 3、6表示补丁开发完成后分支到tags/test中进行测试（不进行
任何合并）；
（3） 4、7表示分支测试完成合并到主干解决冲突，其中4是将和
sp01合并；7是将+sp01和sp02合并，
（4） 5、8表示将合并后的主干生成测试分支进行测试。
（5） 如果两个分支开发完成时间接近，则进行版本变更，两个分支
合并到一起发布。
合并的具体操作说明见附件1“利用SVN进行合并操作说明”
补丁发布和管理
（1） 补丁生成之后版本经理通过jira提交发布申请到质量部，质
量部进行审批。发布申请中要包含以下内容： ? 补丁安装操作说明书 ? 补丁更新说明书 ? 补丁程序 ? 数据库脚本 ? 测试报告
备注：为保证补丁包的通用性，补丁安装操作说明书中不涉及系统功能的配置，仅描述如何打补丁；数据库脚本仅针对通用的数据库调整（指数据库对象，包括表、视图、函数、
补丁包管理规定
