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