《20100629软件版本管理》由会员分享，可在线阅读，更多相关《20100629软件版本管理（3页珍藏版）》请在金锄头文库上搜索。
1、软件版本管理软件版本管理工具：SVN使用规范如下： 版本号版本号按照月度来划分。（版本标识为 Vx.y, x 值逐一增大， y 值保持不变）例如，六月底版本号是 V1.0，到七月底版本号变成 V2.0。版本中的代码文件是包含了整个工程文件。注：每更新一次版本，实则是把从 V1.0-V2.0 中间的所有更新包根据文件日期从小到大依次覆盖到 V1.0 中，从而产生出 V2.0 的版本。版本文件中不仅要涵盖中间过程中所有 TD 更新包的源代码文件，还要有其对应的 TD 需求文档、设计文档、SQL 和权限更新文档等。另外，有个备注说明文档说明该版本中包含了哪几个 TD 需求。 更新包版本 V1.0-V
2、2.0 之间，有个中间版本过程。该过程以 TD 更新包的形式展现。更新包中的代码文件只包含该 TD 所修改的文件，而不是整个工程文件。标记方式为：项目简称+子系统简称+ TD 编号+ 测试通过日期+ 序列编号例如：大庆医专_ 教务系统_TD360_20100622_1中间过程为：一个 TD 编号为一个更新包。每个 TD 编号文件夹下面，又分为源代码，编译码，文档这三个模块文档。其中源代码是指开发的代码文件，编译码是指测试部通过编译后产生的代码文件，文档是指对应该 TD 产生的需求文档、设计文档、SQL 和权限更新文档等。如图所示：另：Beta 表示项目组内部测试版（未经过测试部门进行的测试，例
3、如开发部直接给实施人员进行的测试）； Release 表示项目组外部测试版（测试部门已经测试并通过） 。在月度版本中，已进行系统测试过的用Release表示，未进行系统测试过的用Beta表示。注：如果是没有 TD 编号的需求更改，文档名称则以该需求的功能模块来命名。 文档每个版本中的文档内容包含：需求文档、设计文档、单元测试报告、系统测试报告、SQL 和权限更新文档。文档命名规则：项目简称 + 资料名称+ TD 编号 + 日期 例：湖大教务系统_需求分析说明书_TD368_20100622注：如果是没有 TD 编号的文档，文档名称则以该需求的功能模块来命名。 产品出库确认单每完成一个版本并交付
4、给运维部门以后，配置员填写产品出库确认单。 确认该版本完成了哪些 TD 和交付日期并给各部门负责人签字。 对各部门的规范要求1) 运维部门：a) 项目阶段计划中明确在这一时间段内要完成的是哪些 TD，其中最紧急的是哪几个 TD。如果是在该计划外的紧急需求 TD，需要通过审批领导确认签字后通知到相关部门。b) 在更新包或版本交付给客户之前，要先确认是否会存在问题。如若存在问题，应及时反馈给测试部。2) 开发部门：a) 开发人员在用 SVN 提交源代码的时候，必须写上 TD 编号以及功能模块描述。如果不是针对 TD 上的问题进行的修改，备注上写明功能模块描述;规范代码提交操作，尽量避免提交文件遗漏
5、或者是代码覆盖等问题的出现。b) 如果是对程序的父类、全局变量或者静态变量等进行了修改，需要集相关开发人员进行讨论，并在提交文件时注明修改了（父类、全局变量或者静态变量等） ，以免影响其他功能的使用。3) 品质部门：品质部测试通过后，把测试通过的 TD 编号提交给配置管理员，并注明该 TD 是哪个学校、哪个系统、用的什么开发语言。4) 配置管理员：a) 配置管理员从测试环境中下载已测试通过的 TD 相应修改文件，然后再连带文件目录路径一起上传到 SVN-基线库中。在上传到基线库前，查看每个被修改文件的历史记录，如果发现有多个 TD 编号都对该文件进行修改，则反馈给测试部门着重测试该功能部分，检查功能是否被覆盖。b) 每周进行一次把更新包更新到月度版本中。c) 发布更新包或版本给运维部门。
