《软件配置管理规范实施细则.doc》由会员分享，可在线阅读，更多相关《软件配置管理规范实施细则.doc（45页珍藏版）》请在三一文库上搜索。
1、 软件配置管理规范软件配置管理规范 XXXXXXXXXXXXXXxXXXXXXXXXXXXXXx 科技有限公司科技有限公司 i 目目 录录 1配置管理规范配置管理规范.1 1.1概要1 1.1.1 内容.1 1.1.2 适用范围.1 1.1.3 术语和缩略语.1 1.2相关人权责3 1.2.1 项目经理（Project Manager，PM）.3 1.2.2 配置控制委员会（Configuration Control Board，CCB）3 1.2.3 配置管理员（Configuration Management Officer，CMO）3 1.2.4 开发人员（Developer）.4 1.
2、2.5 测试人员（Tester）.4 1.2.6 软件质量保证员（Software Quality Assurance，SQA）4 1.3实施细则5 1.3.1 配置控制委员会的成立.5 1.3.2 确定配置策略.5 1.3.3 制定配置管理计划.6 1.3.4 配置项管理.7 ii 1.3.5 配置库管理.11 1.3.6 配置项基线管理.14 1.3.7 配置变更控制.16 1.3.8 配置状态报告.21 1.3.9 配置审核.21 1.3.10 发行管理.22 1.4相关文件23 1.4.1 配置管理计划.23 1.4.2 配置库管理报告.23 1.4.3 配置项变更控制报告.23 2版
3、本控制版本控制结合结合 CVSCVS 实现实现.24 2.1概要24 2.2总体处理流程25 2.3详细说明28 2.3.1 修改的过程.28 2.3.2 冲突的解决.30 2.3.3 CVS 提交中注释和标签的要求.31 2.3.4 WinCVS 日常使用.34 2.3.5 基本的 CVS update/commit 操作规范.35 2.3.6 测试（坚持每日构建）.36 2.3.7 开发、质保、测试、发布的过程.37 iii 3变更管理变更管理结合结合 CVSTRACCVSTRAC 实现实现.38 3.1目的38 3.2变更过程38 附件：配置库的创建流程附件：配置库的创建流程.41 1
4、1 配置管理规范 1.1概要 1.1.1内容 本文用来规范配置管理活动，确保配置项正确地唯一标识并易于 存取，保证基准配置项的更改受控，明确基线状态，在整个软件生命 周期中建立和维护项目产品的完整性和可追溯性。 1.1.2适用范围 对于不同类别的软件项目，配置管理的流程不同，可在本流程的 基础上进行裁减。 1.1.3术语和缩略语 1.1.3.1 软件配置管理（Software Configuration Management，SCM） 软件配置管理是对软件修改进行标识、组织和控制的技术，用来 协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过 程和生命周期进行控制、规范的一系列措施。
5、配置管理的目标是记录 软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都 能得到精确的不同版本的产品配置。 1.1.3.2 配置项（Configuration Item，CI） 凡是纳入配置管理范畴的工作成果统称为配置项，配置项逻辑上 组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试 的。 2 配置项主要有两大类： 1)属于产品组成部分的工作成果，例如需求文档、设计文档、源 代码、测试用例等； 2)项目管理和机构支撑过程产生的文档。这些文档虽然不是产品 的组成部分，但是值得保存，如会议纪要、交流记录等。 每个配置项的主要属性有：名称、标识符、文件状态、版本、作 者、日期等
6、。所有配置项都被保存在配置库里，确保不会混淆、丢失。 配置项及其历史记录反映了软件的演化过程。 1.1.3.3 基线（Baseline） 在配置管理系统中，基线就是一个配置项或一组配置项在其生命 周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些 配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化” 。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素 （配置项）的一个版本，且只确定一个版本。一般情况下，基线一般 在指定的里程碑处创建，并与项目中的里程碑保持同步。每个基线都 将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再 被任何人随意修改，对其修改要严
7、格地按照变更控制的过程进行。在 一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形 成下一个基线。 基线的主要属性有：名称、标识符、版本、日期等。 3 1.2相关人权责 1.2.1项目经理（Project Manager，PM） 责任与权利： 1)接收或拒绝小范围的变更； 2)提出管理管理的建议和要求； 3)发布管理； 4)配合部门、公司质量管理员工作； 5)指派项目的质量管理员； 6)考核项目组成员规范的执行情况。 1.2.2配置控制委员会（Configuration Control Board，CCB） 责任与权利： 1)制定和修改项目的配置管理策略； 2)批准、发布配置管理计划
8、； 3)建立、更改基线的设置，审核变更申请； 4)根据配置管理员的报告决定相应的对策。 1.2.3配置管理员（Configuration Management Officer，CMO） 责任与权利： 1)执行版本控制和变更控制方案； 2)负责项目的配置管理工作（包括环境的搭建、权限分配、 配置库的建立、配置项的控制等） ； 3)配置管理工具的日常管理与维护； 4 4)配置库的日常操作和维护； 5)负责配置审核并提交报告； 6)根据项目经理批准生成发布版本； 7)对开发人员进行相关的培训； 8)对配置审核中发现的不符合项，要求相关责任人进行纠正。 1.2.4开发人员（Developer） 责任与
9、权利： 1)根据确定的配置管理计划和相关规定，提交配置项和基线； 2)负责软件集成和版本生成。 3)按照软件配置管理工具的使用模型来完成开发任务。 1.2.5测试人员（Tester） 责任和权利： 1）根据配置管理计划和相关规定，提交测试配置项和测试基 线； 2）负责软件变更的测试验证，包括日测试、集成测试、发布 测试 1.2.6软件质量保证员（Software Quality Assurance，SQA） 责任和权利： 1）负责配置审核并提交报告。 5 2）对配置审核中发现的不符合项，要求相关责任人进行纠正。 1.3实施细则 1.3.1配置控制委员会的成立 1.3.1.1 配置控制委员会成员
10、组成 配置控制委员会成员人数一般为奇数，人数在 37 人范围内， 根据各个项目的不同，顾客代表和主要开发人员可以不同。CCB 成员 一般包括： 1)部门经理； 2)项目经理； 3)配置管理员； 4)测试人员； 5)顾客代表； 6)主要开发人员等。 1.3.1.2 配置控制委员会的决策机制 寻求配置控制委员会成员的一致意见。若不能达成一致，可在听 取意见后由配置控制委员会的组长最终决定。 1.3.2确定配置策略 1.3.2.1 配置策略确定的时机 1）配置控制委员会根据项目的开发计划确定各个里程碑； 2）配置管理员负责整理确定的项目基线和配置项列表，并 6 在编制配置管理计划时列明； 3）配置管
11、理员按约定时机收集配置项和建立初始基线。 1.3.2.2 配置项的范围 1)1)技术文档（技术文档（DocumentsDocuments）：）：项目开发计划、需求分析报告、软 件设计书、质量保证计划、概要设计书、详细设计书、测试文档、技 术报告、用户手册、总结报告等； 2)2)程序（程序（ProgramProgram）：）：阶段产品、计算机程序、源程序、释放产 品等； 3)3)工具（工具（ToolsTools）：）：自动设计工具、开发工具、测试工具、维护 工具等； 4)4)交互文档（交互文档（CommunicationsCommunications）：）：与客户或项目组内交互产生文 档，如会谈
12、记录、E-mail、会议纪要、MSN 记录等。 1.3.3制定配置管理计划 1.3.3.1 配置管理计划的编制 通常情况下，由配置管理员在设计完成后，开始编制配置管理 计划 ；如有特殊需要，也可以根据合同或项目要求，由配置管理员 在某一项目或项目的某一阶段开始前制定配置管理计划 。 1.3.3.2 配置管理计划的内容 配置管理计划应包括以下方面的内容： 1) 该项目对配置管理的要求； 2) 实施配置管理的责任人、组织及其职责； 7 3) 需要开展的配置管理活动及其进度安排； 4) 采用的方法和工具等。 1.3.3.3 配置管理计划由配置管理委员会负责审批。 1.3.4配置项管理 1.3.4.1
13、 配置项标识要求 1) 合同有明确标识和追踪要求时，由开发人员按合同要求进行 标识，以保证满足合同追踪要求。 2) 在开发过程中项目组人员提交的配置项，由项目组人员按照 本节相关部分标识规则进行标识。 3) 项目组人员将要标识或已标识的配置项提交到配置库统一管 理，并填写详细的备注信息。 1.3.4.2 版本管理 1.3.4.2.11.3.4.2.1文档版本控制文档版本控制 所有文档的管理纳入配置管理库，用版本控制工具进行统一管理。 文档的版本控制主要通过文档的名称、文档控制页及版本控制工具的 标签来实现，主要分为以下几类： 1、有版本变化的 命名方式：文档名 适用文档：项目开发计划书，项目配
14、置管理计划，用户业务需求， 需求分析说明书，总体设计说明书，详细设计说明书，数据库设计说 明书，模块测试用例卷宗，用户使用手册等。而版本信息使用标签来 8 控制说明，标签结构如下： 大版本大版本 + + 子系统简称子系统简称 + + 版本号版本号 + + 日期日期 大版本大版本 ： 可选 ，表示同一项目为不同用户定制的版本。 子系统简称子系统简称 ： 可选，当一个项目有多个子系统时，为区分不 同子系统而设置。 版本号版本号 ：采用Vx-yy的形式。具体说明如下： a.文档发布名称采用文档名+Vx-yy的形式，文档的版本号应该 和版本控制工具中相应标签上的版本号一致。 b.对文档的修改需要从配置
15、管理库中取到本地进行。 c.对于文档小的修改，如文字错误，格式调整，不需要进行标签 的变化。 d.文档内容没有大的增加和删节，意思表述没有发生重大的变化， 版本标识通过版本工具中加上 yy 标签来表示（如：V1-01） ，以及在 文档内部控制页标注变化来表示。 e.文档有重大增加和删节，意思表述有重大变化的，版本标识通 过在相应文档加上 x 标签来表示（如：V2-00） 。 f.对于纳入基线库的文档的修改需要提交变更申请，经批准才能 进行修改，并且修改的内容要经再次评审才能重新纳入基线库，作为 后续阶段的参考文档。 2、非正规次要的文档 命名方式：文档名+（日期） 9 适用文档：情况总结，各种
16、报告等不需要通过名称明确进行标识 变化过程的文档。 示 例：培训情况总结（2005 年 1 月 10 日）.doc 、主要区别在于时间的 命名方式：文档名撰写时间 适用文档：文档名称有明确的含义，需要用时间标识的日常性文 档。如周例会会议纪要，项目月计划，项目月总结等等。 示 例：周例会会议纪要 20030901.doc 、主要区别在于阶段的 命名方式：阶段名文档名 适用文档：使用于不同阶段的文档，需要加阶段名称来标识文档， 有时可能也需要加版本号，如 阶段计划，阶段总结等。 示 例：需求调研阶段计划.doc，总体设计阶段计划.doc，试 运行阶段计划.doc 、 其他文档： 对于不能按照前四
17、种类型进行命名的文档 会议纪要会议纪要：会议纪要 YYYYMMDD ( ) 示 例：9 月 9 日召开的项目启动会 命名为：会议纪要 20030909(项目启动).doc 年月日 内容简述 10 评审报告评审报告：评审报告 YYYYMMDD ( ) 同”会议纪要”要求。 示 例：10 月 9 日召开的项目总体方案评审 命名为：评审报告 20030910(总体方案).doc 1.3.4.2.21.3.4.2.2发行版本表示发行版本表示 发行版本采用标签说明，结构如下： 大版本大版本 + + 子系统简称子系统简称 + + 版本类型版本类型 + + 版本号版本号 + + 日期日期 大版本大版本 ：
18、可选 ，表示同一项目为不同用户定制的版本。 子系统简称子系统简称 ： 可选，当一个项目有多个子系统时，为区分不 同子系统而设置。 版本类型：版本类型：分为 3 种 Beta 表示项目组内部测试版、日测试（标签） ， Release 项目组外部测试版、集成测试（标签） ， Version 正式发行版。 版本号版本号 对于 Version 正式发行版 是必须要注明的，而其它可 选。 发行产品基线在版本号前加 Version，如 Version_1, Version_2, Version_3.表示分支； Version_1_0, Version_1_1, Version_1_2 表示在分支 Vers
19、ion_1 上的标签； Version_0_0, Version_0_1, Version_0_2 表示在主线上 11 的标签。 1.3.5配置库管理 1.3.5.1 配置库（Repository）的分类 配置库统一由配置管理员负责管理，主要使用 CVS 版本工具。配 置库目录结构如下： 一级目录二级目录说明 01_worksho01_worksho p p 个人私有目录，里面保存开发者文件，提供备份功能 保存程序中的源代码 BinBin 二进制文件目录，存放应用程序的可执 行文件 DatabaseDatabase 数据库目录，包含数据库表结构、存储 过程等对象 HelpHelp 帮助文件目录
20、，包含使用帮助文档 InstallInstall 安装程序目录，存放安装程序源文件 PackagesPackages 安装包目录，包含应用程序的安装文件 和补丁包 02_sourcec02_sourcec odeode SourceSource 源代码目录，源码放于该目录下 开发包文档目录，里面包含设计开发文档以及各种开发规范文档 0 管理活动 项目管理相关文档 1 会议纪要以月为单位建立目录，如 2005-01 2 软件产品宣传资 料 03_documen03_documen t t 第 01 阶段(项目启 动) 可行性研究报告、项目任务书、需求说 明 12 第 02 阶段(需求调 研) 需
21、求分析说明书 第 03 阶段(项目计 划) 体进度说明、进度跟踪、配置管理计划、 质量保证计划、测试计划 第 04 阶段(系统设 计) 概要设计、详细设计和数据库设计 第 05 阶段(编码阶 段) 第 06 阶段(测试阶 段) 测试计划、测试用例、测试结果和测试 分析报告 第 07 阶段(交付验 收) 付施工文档、工具 第 08 阶段(项目总 结) 项目质量报告、测试报告 第 09 阶段(部署)项目推广相关文档包括操作手册、安装 维护手册、维护文档以及必要的业务和技术 培训文档 04_tools04_tools 工具目录，存放开发中使用的相关工具软件 1.3.5.2 配置库的建立 所有项目应建
22、立配置库，以便管理各配置项，配置管理员组织建 立配置库。程序库主要通过设置版本的分支来实现对配置项权限管理： 1)开发库：在主线上，对应的是开发人员的私有开发空间。开发 人员根据任务分工获得对相应配置项的操作许可之后，在主线上工作。 2)控制库：通过分支实现，建立控制分支。 13 3)版本库：通过在控制库上建立标签实现。 配置库统一由配置管理员管理，根据各开发阶段的实际情况定制 相应的版本选取规则，来保证开发活动的正常运作。在变更发生时， 应及时做好基线的推进。 1.3.5.3 分配权限 配置管理员为每个项目成员分配配置库操作权限。一般地，项目 成员拥有 Add、 Check in/Check
23、out 等权限，但是不能拥有“删除” 权限。配置管理员的权限最高。 存取权限 配置管理项人员角色 读 增 加 修 改 删除 公司质量管理 员 部门质量管理 员 项目经理 项目质量管理 员 开发工具库 项目组成员 项目文档库 基线 公司质量管理 员 部门质量管理 员 14 项目经理 项目质量管理 员 项目组成员 公司质量管理 员 部门质量管理 员 项目经理 项目质量管理 员 项目文档库 阶段文档 项目组成员（对己） 公司质量管理 员 部门质量管理 员 项目经理 项目质量管理 员 软件开发库 项目组成员 （他人和以做基 线控制不允许） 1.3.5.4 配置库的操作与管理 1)开发人员根据获得的授权
24、进行研发工作，操作配置库，例 如 Add、Check in / Checkout 等。 2)配置管理员根据配置管理计划创建与维护基线， “冻结”配 置项，控制变更。 15 3)配置管理员定期备份配置库。 1.3.6配置项基线管理 配置管理员根据配置管理计划，对配置项和基线进行分阶段管理。 1.3.6.1 项目启动 配置项包括可行性研究报告可行性研究报告、项目任务书项目任务书、需求说明，需求说明，评审通过 后建立发布基线。 1.3.6.2 需求分析 系统调研后开发人员进行需求分析，并整理需求分析说明书需求分析说明书。需 求分析说明书通过评审并取得客户的确认后，建立需求基线。如需升 级版本则必须通
25、过评审并得到客户的确认。 1.3.6.3 项目计划 需求分析完成后即可制定项目的开发计划，包括项目总体进度说总体进度说 明、进度跟踪、配置管理计划、质量保证计划、测试计划明、进度跟踪、配置管理计划、质量保证计划、测试计划等。项目开 发计划评审通过后，建立项目计划基线。 1.3.6.4 系统设计 系统设计可分为概要设计、详细设计和数据库设计概要设计、详细设计和数据库设计等部分。针对 需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分 析报告版本的对应关系。设计书评审通过后，建立设计基线。 1.3.6.5 编码 编码按功能模块分子项目，即每个模块记作一个配置项。代码基 16 线分别在日测
26、试后建立 Beta 版，在集成测试时建立 Release 版，产 品正式发布时建立 Version 版。 1.3.6.6 测试 各测试阶段应提供测试计划、测试用例、测试结果和测试分析报测试计划、测试用例、测试结果和测试分析报 告告，项目启动后应提供项目测试计划书，项目验收结束后应提交项目 测试总结报告等。配置时应说明测试的版本与编码版本的对应关系。 各阶段测试（如单元测试、集成测试）完成后建立测试基线。 1.3.6.7 交付与验收 在交付前配置审核完成后建立产品基线，产品基线包含程序以及 有关文档配置项，包括交付施工文档、工具付施工文档、工具等。 1.3.6.8 项目总结 项目总结应经过部门内
27、部评审，包括项目质量报告、测试报告项目质量报告、测试报告等。 1.3.6.9 产品部署 部署时应包括操作手册、安装维护手册、维护文档以及必要的业括操作手册、安装维护手册、维护文档以及必要的业 务和技术培训文档务和技术培训文档。 1.3.6.10相关资料 相关资料也应作为配置项纳入配置管理，此部分包括： 1) 相关法律、法规； 2) 必须遵照或项目组约定的技术规范； 3) 与客户或项目组内部重要的交互信息记录，如会议记录、会 17 谈记录、e-mail 和 MSN 记录等； 1.3.7配置变更控制 1.3.7.1 变更的分类 软件及其相关文档的变更按照变更的影响范围进行分类： 1)A 级：变更会
28、影响系统级的需求、外部接口、产品价格或者交 付期；这类变更必须经过配置管理委员会审核并有客户批准和确认。 2)B 级：变更会影响配置项间的功能接口、内部功能的设计、组 件；这类变更必须由项目经理或配置管理委员会的批准和认可。 3) C 级：变更只会影响配置项内部或对 BUG 问题的处理；这类变 更可以由配置项的管理人员负责批准。 18 19 图 2 变更控制流程 1.3.7.2 变更请求的提出 a由发起者（客户、最终用户或开发部门）确定变更，填写 配置项变更控制报告 ，描述变更原因和变更内容，并提交给配置 管理员。 b配置管理员对申请表是否清晰、明确和完整性进行审查， 若发现变更不明确或不完整
29、，应返回申请者。对通过审查的变更申请 分配变更 ID，以便跟踪和记录变更信息。 1.3.7.3 变更评估 a配置管理员将配置项变更控制报告发送给项目经理 （或者其他授权人员） ，由项目经理负责对变更进行评估。 b变更控制的一个重要环节就是变更评估，变更评估要分析 每个变更对系统功能、接口、成本、进度以及约定需求的影响，同时 还要分析对软件安全性、可靠性、可维护性、可移植性和性能的影响。 c变更评估产生的文档应描述若实施此变更而必须变更的配 置项、文档和资源；变更评估文档在完成变更评估后发送给配置管理 员。 d配置管理员收到评估后的配置项变更控制报告后，更 新变更记录，同时向配置管理委员会提交变
30、更申请。 20 1.3.7.4 变更审核 aCCB 对提交的变更申请进行审核，并根据变更评估确定变更 的影响级别；CCB 审核可能的结果有三种：接受变更；拒绝变更；延 期变更。CCB 也可能需要更多的变更分析的信息。 bCCB 批准的变更，由配置管理员将变更项目发送到指定的开 发人员进行下一步的实施变更工作；对于拒绝的变更，由配置管理员 将拒绝变更的原因发送给发起者，并保存配置项变更控制报告 ， 更新变更记录，关闭变更活动。 c配置管理员负责整理 CCB 会议记录，填写配置项变更控 制报告中相应审核项；更新变更记录；将变更文档分发给相关人员。 1.3.7.5 变更实施 a变更被批准后，开发人员
31、开始实施变更，并详细记录变更 的内容；项目管理部门要对变更的实施进行跟踪。 b对于代码变更，必须修改设计、代码、测试以及对变更正 确性的验证。而且与变更相关的文档必须修订，以反映变更。当变更 以及测试完成后，进行提交。 c对于开发计划、配置管理计划发生变更的，项目组人员要 按照变更过的开发计划、配置管理计划提交配置项。 1.3.7.6 变更确认 a变更后的程序提交后必需经过测试组进行回归测试，以确 21 保变更没有引入新的 Bug。不会引起程序变更的文档（如计划文档） 的变更不需经过测试。 b通过测试后，质保人员需对变更进行审核，审核的范围一 般涉及以下方面： 测试记录；变更请求；配置项的检入
32、及检出；文件的命名；版本 的编号。 c审核后，由配置管理员更新到基线库中。 1.3.8配置状态报告 1.3.8.1 配置状态报告的目的 记录和报告整个软件生命周期演化状态。 1.3.8.2 配置状态报告记录的内容 配置状态报告记录的内容包括： 1) 软件和文档的标识； 2) 目前状态； 3) 基线演化状态； 4) 变更状态； 5) 版本交付信息等。 1.3.8.3 配置状态报告的生成 配置管理报告自第一个基线创建时建立，由配置管理系统生成， 及时反映当前配置状态。 22 1.3.9配置审核 1.3.9.1 配置审核的类别 配置审核分为： 1)功能配置审核（Functional Configur
33、ation Audit，FCA）： 审核软件功能是否与需求一致，并符合基线文档要求；通常要审查测 试方法、流程、报告和设计文档等。 2) 物理配置审核（Physical Configuration Audit，PCA）：审 核要交付的组成项是否存在，是否包含所有必需的项目，如正确版本 的源代码、资源、文档、安装说明等等。 1.3.9.2 配置审核执行的时机 通常选择以下几种情况由质量保证人员负责实施配置审核： 1)软件产品交付或是软件产品正式发行前； 2)软件开发的阶段工作结束后； 3)在产品维护工作中，定期地进行。 1.3.9.3 不符合项的处理 对配置审核中发现的不符合现象，SQA 进行记
34、录，并交由责任部 门限期进行纠正，SQA 负责纠正措施的验证。所有的不符合项报告均 关闭后，才能发布新版本。 23 1.3.10发行管理 1.3.10.1通过配置审核后，经项目经理批准，由配置管理员 负责生产新版本。 1.3.10.2交付管理 这里“交付”是指从配置库中提取配置项，交付给客户或项目外 的人员。交付出去的配置项必须有据可查，避免发生混乱。流程如下： 1)“索取人”向 CCB 提出交付申请。 2) CCB 审批该申请。如果该申请不合法（合理） ，则拒绝交付配 置项。如果同意交付，CCB 应给出详细的交付清单。 3) 配置管理员依据 CCB 的批示，从配置库中提取配置项交付给 “索取
35、人” 。 4)“索取人”验收后签字。 1.4相关文件 1.4.1配置管理计划 1.4.2配置库管理报告 1.4.3配置项变更控制报告 24 2 版本控制结合 CVS 实现 2.1概要 众所周知，软件配置管理为软件开发提供了一套管理办法和活动 原则，成为贯穿软件开发始终的重要质量保证活动。配置管理的过程 实际是软件开发过程中质量管理的精髓所在，版本管理提高了开发者 的工作效率，而变更控制则提高了整个开发团队的工作效率。两者的 紧密结合，将为软件开发项目提供一道坚实的质量防火墙，使软件开 发项目的质量得到保障。 版本控制是实施变更管理的基础，本章结合并发版本控制软件 CVS，实现项目过程中对版本的
36、控制和对产品交付的控制。软件配置 管理工具采用 CVS(开放源代码、并发版本控制软件流程)。因为 CVS 只是一个开发一级的版本控制工具没有版本库、开发库、控制库之间 的管理。本文提出关于 3 个库的一种管理办法，用以保证开发库和控 制库之间数据的一致性。为进一步实现测试驱动开发、滚动开发、日 构建技术在项目组中的应用打下坚实的基础。 25 2.2总体处理流程 充分利用 CVS 工具的功能，结合我部门软件项目的实际情况，对 两个工具使用方式进行调整，实现开发、测试、发布的合理化流程， 流程图如下： 26 1)CVS 的主线是开发库，所有开发都是在主线上完成。这种 开发方式与在分支上开发相比，好
37、处是：避免了由于建立过多的开发 分支，使开发者不知道哪个分支是最新的版本,引起的管理繁琐、开 发混乱的问题。 27 2)增加新功能或修改程序时，可以在开发主线上随时提交修 改内容，但是在修改完成，并通过自己的测试（单元测试）之后，需 要建立标签-OK,用来通知 CVS 可以进行日构建测试和集成测试。 但是需要说明如果需要代码复审员对代码复审，则开发者要先建立完 成标签，格式为开发者名字+日期（YYYYMMDD）+任务单号（或者完成 任务的名称） ，用来区分多个提交的任务。标签建立完后由代码复审 员对复审通过的代码设置标签-OK 。 3)进行日构建测试时，要取标签为OK的版本，并建立日 构建测试
38、标签SS_MM_Beta_DATE_N 。此过程要求在夜间完成，并产 生测试记录。 SS 表示不同版本：如为不同用户定制的版本; MM 表示子系统名称：如 QT-前台；HT-后台； DATE 表示当前日期:格式 YYYYMMDD N 表示本日的第几次测试，可以不写。 以下 SS、MM、DATE、N 含义与此相同。 4)集成测试时（产生内部测试版，产生的版本不是用来进行 推广使用的版本） ，建立新的内部测试标签SS_MM_Release_DATE_N ， 只是记录测试问题时用于标识执行的是哪个版本。 5)如果要进行发布，那么取经过日构建测试的标签版本，建 立发布分支SS_MM_Version_X
39、_DATE ，(X 表示发布版本号)在此分 支上进行测试，在测试时开发人员可以继续在开发主线上开发新的功 28 能，而不必冻结开发代码。此测试时间要求在 3 天之内完成，所以最 好是周三建立发布分支，这样可以在周一进行新版本的发布。在此分 支上进行测试，测试出来的问题分为两种： a. 必须在此版本发布之前解决掉的问题，要求相应的开发人员 在分支上进行修改完善，反复进行测试，直到所有此类问题都已解决。 之后在这分支上建立发布标签SS_MM_Version_X_Y_DATE ，并在发 布系统中注明此发布版本。 b. 不是必须要解决的问题，则可以放到以后的版本中解决处理， 不要在此次版本发布上修改，
40、从而保证该版本能够按时发布。 此分支是受控分支，对此分支的修改要严格进行变更管理。 2.3详细说明 2.3.1修改的过程 开发者从 CVSTRAC 中读取任务单或者计划任务，一般原则上先处 理测试组提交的 bug 修改，后对计划部分的功能进行开发工作。当我 29 们开始一个新的修改时，工作流程如下： 首先要做的是从代码库中提取出一份最新的副本(通过 update 操作完成)； 之后通知 CVS 服务端你要在本地进行修改(尽量使用 reserved edit 来完成)，查看是否有其他人在修改此模块，如果有 人在修改，那么要先进行沟通，之后再做修改； 30 最后修改完成、进行粗调之后，则应尽快将代
41、码提交回代码 库(通过 commit 操作完成)。 基本的 update 和 commit 操作流程如下图所示： 图 1. CVS update 和 commit 2.3.2冲突的解决 如果出现两个开发者同时修改同一个文件的情况，例如，两个开 发者同时地修改了同一个文件的同一个版本，这种情形称为冲突： 图 2. CVS 并行开发中的冲突 冲突的原因是开发者 B 修改完代码之后，他首先提交。在 A、B 从代码库中提取代码时，最新版本是 1.1，于是 B 提交的版本被版本 控制系统命名为 1.2。但不久后，A 想要提交代码，版本控制系统将 31 拒绝他的提交，因为他的修改基于代码的 1.1 版，而
42、目前的最新版本 已经是 1.2 了。 CVS 提供了自动合并功能，来解决这种冲突，但是还是需要人来 审核,当发生冲突时，要由后一个提交者解决冲突。于是，修改流程 如下图： 图 3. 开发者 A 解决冲突，并提交 2.3.3CVS 提交中注释和标签的要求 CVS 在提交代码时需要填写提交的注释，项目组使用统一格式来 达到规范的目的。 2.3.3.1 提交注释的格式符号 模块名 详细注释 其中， “符号符号”可以是！、(可以省略) 两个符号之一。表示开 发工作的两种状态：完成-！和进行中- 。 完成完成-！ ，表示经过测试完成，可以提交到控制库，此时标 签需要设置OK 。 进行中进行中- ，表示正
43、在对问题和功能处理中，此部分提交的内 容只是表示开发库的内容，还没有测试完成，不能提交到控制库之中。 其中模块名模块名 表示修改的是哪个模块，如网点，后台、数 32 据库、设计文档等等。 其中详细注释详细注释要指出此部分的提交属于哪部分内容：包括: 新增加的功能;删除旧的功能;修正错误;任务单号; 计划要完成的功 能等等，还要详细说明为什么进行代码的修改，以及进行了什么样的 修改。 例如：以下是提交（注意符号和中括号之间有一空格）： ！ 发行后台 增加功能，解决打印份发表时总是出现乱码的问 题。修改了打印函数 f_print() 第 50 行的打印语句 print。 2.3.3.2 可以做日构
44、建测试的完成标签-OK 在完成一个开发任务之后，并自己测试（单元测试）通过之后， 如果可以提交到控制库的代码，则需要建立（或移动）标签OK到 此版本上，用来通知 CVS 可以进行日构建测试和集成测试。也就是说， 要保证OK标签永远标在最新经过单元测试的版本上。如果开发者 的代码需要复审，则此建立或者移动标签-OK的工作由代码复审 员完成。 2.3.3.3 提交给代码复审员进行代码复审的复审标签-CK- MINGZI-YYYYMMDD-N 对于代码需要做复审的，当开发者的代码经过自己测试完成后， 就需要由开发者建立复审标签，同时通知复审员可以进行代码复审了。 复审完成通过后，由代码复审员建立完成
45、标签-OK 。 复审标签FS-MINGZI-YYYYMMDD-NFS-MINGZI-YYYYMMDD-N的说明： 33 CK-CK- 表示此标签为需要做代码复审 MINGZI-MINGZI- 表示表示开发者名字 YYYYMMDD-YYYYMMDD-为为 8 8 为的为的日期，如 20040704 N-N- 任务单编号，通过此编号可以知道此次代码修改或增加要 解决的问题 2.3.3.4 日构建测试标签-SS_MM_Beta_DATE_N Beta 表示此标签为日构建测试时建立的标签； DATE 建立此标签的日期，格式 YYYYMMDD。 2.3.3.5 内部集成测试标签-SS_MM_Releas
46、e_DATE_N Release 表示此标签为内部集成测试时建立的标签； DATE 建立此标签的日期，格式 YYYYMMDD。 2.3.3.6 建立发布分支-SS_MM_Version_X_DATE Version 表示为产品发布做测试而建立的发布测试分支; X 表示版本号； DATE 建立此分支的日期，格式 YYYYMMDD 2.3.3.7 这建立发布标签（即产品发布版本号） SS_MM_Version_X_Y_DATE Version 表示经过测试之后，可以进行发布的版本而建立的标签； X 表示发布版本号，0 表示在主线上发布，1、2、3表示在分支 上发布； 34 Y 表示发布的补丁号，0
47、 表示 X 版本的第一次发布； DATE 建立此标签的日期，格式 YYYYMMDD。 2.3.4WinCVS 日常使用 2.3.4.1 wincvs 日常使用指南.pdf 本文档介绍了 WinCvs 1.0.x 客户端的日常使用。不是介绍版本 控制系统，也不是介绍 CVS，更不是介绍 WinCvs。适用于当你大概知 道你要做什么，但又不十分清楚如何作。 2.3.4.2 移动标签的方法 如下图所示： 在建立标 签的窗口里（菜单 MODIFYCREATE A TAG ON SELECTION） ，选中 Overwrite existing tags with the same name,之后在 N
48、ew tag name 中输入要移动的标签名称，确定即可。 2.3.4.3 修改备注（log ）的方法 如下图所示： 35 选择要修改 log 的文件，查看其版本分支图（菜单 QueryGraph） ，鼠标右键单击要修改 log 的版本，在弹出菜单下选 择 Admin optionschange log message 在弹出的窗口里，就可以修 改 log 信息。要注意修改完成后，需要重新察看版本分支图才能看 到修改信息。另外，只有系统管理员才能修改 log 信息。在 cvsroot 目录下 admin 文件里的用户才使系统管理员。 2.3.5基本的 CVS update/commit 操作规范 简单的 CVS 操作约定 修改文件之前首先 update。这意味着修改时的版本尽可能新， 36 一旦发生冲突，解决它的工作量会比较小。 及时 commit。本地代码与代码库中的代码差异越小，别人合并 的难度也就越小(他们有比较大的概率能够拿到新的版本) 将不同的功能单元修改分开 commit。一方面，这样做能够尽早 地 commit，减少别人合并的难度；另一方面，由于 CVS 提供了回退到 先前版本的能力，一旦由于某项功能修改造成问题，也很容易将那次 修改的内容，而不是整个修改回退到正常的代码。 同一