SVN配置管理培训

1、1 基本概念基本概念 2 配置管理的目的 配置管理的基本概念 配置管理的职责划分 配置管理的活动3配置管理过程的目的是：配置管理活动是有计划的计划中要确定工作产品的基线通过变更控制和配置审计来建立和维护工作产品的完整性。4 cm：配置管理（configuration management）是指对项目生存期过程中的各阶段产品和最终产品演化和变更的管理。 ccb：变更控制组（change control board）是配置项变更的监管组织。 配置项：配置项：指哪些应该纳入配置管理之下，成为受控的工作产品最小单位项。 基线：基线：基线是经过正式评审和认可，作为后续工作依据的配置项集合。 配置审计：配

2、置审计：配置审计主要是验证配置项的完整性和配置项的一致性。5角角 色色职责职责ccb批准建立基线和标识配置项。批准基线的发布。评审与批准基线的更改。批准由基线库生成产品。项目经理协助配置管理员制定配置管理计划。定义基线和配置项。提出发布申请。推动项目的配置管理工作。项目组成员提交配置项产品。针对变更（修改，新增，删除等），提交配置变更申请表。配置管理员制定和维护配置管理计划。建立和维护配置管理系统。标识配置项。发布基线。执行基线审计。标识、保存并分发配置状态报告。从基线库发布产品。质量保证人员（qa）按照计划和过程检查配置管理活动及其工作产品。报告检查中发现的问题，追踪问题直至关闭。6活动1：

3、制定配置管理计划及计划审批7配置管理计划内容： ccb组成 配置管理工具 配置库结构及访问权限 变更项的检入频率 配置项标识规则 识别出的配置项和基线 变更流程 配置审计和状态报告机制 配置库备份方案8 ccb组一般由中层经理、项目经理、关键的开发人员、测试经理、配置管理员、质量保证人员和客户代表等有关人员组成。 ccb组长一般由中层经理担任，中层经理可授权给项目经理，但是中层经理要承担责任。 9 项目经理与配置管理员一起确定配置库结构。一般情况下，配置管理库分为三个区： 开发区：供开发人员使用的配置区。 受控区：保存已被批准的配置项（包括基线）或项目统一管理的过程资产记录。 产品区：将通过系

4、统测试后的产品作为最终产品存放，等待交付客户运行和现场测试。10开发区、受控区合二为一，通过标签来识别受控项目录结构包括： 源程序 模块a 模块b 模块c 文档需求、设计、手册、产品集成、测试、各种计划、对外接口、其它 工具macsv的控制器程序和smartpro共用11 产品区单独分开，存放在空间较大的服务器上。 产品区存放的内容包括：安装盘制作安装盘所用的工程发布单及相关的发布资料映像文件安装文件 产品区由配置管理员管理与维护。12 配置服务器口令由配置管理员或指定人员掌握。 不同角色的人员对配置库的访问权限不同。 产品区只有cm人员有读写权，其他人只能查看。 受控区和开发区合二为一，其中

5、的内容，根据需要分配权限。一般情况下，一个模块由一个人负责维护。 核心资产建一个单独的构件 一个项目的公共服务建一个构件构件的内容：需求、设计、代码、变更记录、构建脚本13 一般情况下，建议配置管理控制的最小层次是：程序模块文件或文档，也就是说，一个程序模块所包含的各个文件不单独进入配置管理的范围，只作为程序模块整体的一部分被增加、删除或更新。 14 例1：一个数据库创建脚本，由一个目录下的多个sql文件组成，这些sql文件被作为一个整体看待。例2：将项目的需求库中的每个需求文档看作为一个配置项。 15 对于基线产品，当发布基线和变更基线时必须将配置项检入； 对于非基线产品，在阶段结束时必须将

6、配置项检入； 对于代码，建议一周至少要检入一次。16 在配置管理计划中，要识别出项目可能的配置项配置项“是什么”、“什么时候置于配置管理之下”包含多个文件的配置项要定义“由什么组成”可以使用一个说明性的readme文件或配置项清单文件来反映每个配置项所包含的内容 17 基线就是经过正式评审和认可的工作产品它作为以后进一步开发的基础只有通过正式的变更控制流程才能对它进行变更如果控制要求严格，则定义多条基线如果控制相对不太严格，则可只定义一条需求基线18常见基线需求分析软件设计 编码 测试 运行系统测试计划、流程、测试数据代码设计软件需求客户需求19推荐的基线基线基线何时建立何时建立控制者控制者需

7、求进入设计环节之前 ccb设计进入测试环节之前 ccb产品进入现场试用环节前ccb20 制定配置管理活动计划列表，明确执行配置管理活动的时间点2122活动2： 创建和维护配置库23按照计划建立配置库，并分配相应的访问权限。定期（至少每月一次）检查配置库的访问权限分配情况，及时收回无权限人员拥有的权限。检查配置库，及时发现和纠正非法操作。不定期变更配置库访问口令，以免口令的泄密。及时删除不再需要的、废除的配置项。24活动3： 发布基线和打标签25提出发布申请，填写基线版本发布版本描述文件配置审计、生成审计报告提交质量审核、ccb审批项目经理解决测试问题 完成发布项目经理配置管理员开始结束noye

8、s26发布基线前一定要给相应的配置项的正确版本打标签，打完标签后，要把标签锁上，以防止他人对标签进行修改，避免造成混乱。也可以对某些中间版本打标签。创建标签时要说明标签的用途。27活动4： 变更控制28非基线产品的变更由项目经理控制：变更申请人提出变更请求，项目经理确认后即可对通知配置管理员开通权限，进行修改。配置管理员开通权限，如果配置项升版，则需对原版本打标签。变更实施人修改配置项时，应记录修改信息，修改完成后通知配置管理员收回权限。添加或删除配置项时，应通知配置管理员。配置管理员更新配置项状态清单。29变更控制-流程图基线产品的变更控制30基线产品的变更：变更申请人向项目经理提交变更申请

9、表。项目经理对变更申请进行初步审核后，提交给ccb评审。ccb组织评估其影响，然后审批，指定变更实施人，并把配置变更申请表交给配置管理员。配置管理员将批准的配置变更申请表纳入配置管理库变更实施人员完成修改后，由指定的人员进行验证。配置管理员更新基线，保证基线产品中的配置项均已被check in，锁定需要进行变更的基线及其产品，提升基线到变更状态（即，将基线版本升级）。配置管理员填写配置项状态清单表，并将变更情况通知相关人员。31活动5： 创建版本分支32 当一个新的功能版本衍生时，项目经理要写一个说明给配置管理员，说明要创建一个版本分支，创建分支的目的是什么，以主线上的哪个版本为基础创建分支，

10、分支与主线的关系，以及将在什么时间点与主线合并，谁在分支上工作。33不建议创建太多分支。分支多会造成管理的混乱和困难。分支多，合并的工作量就会很大。如果建了很多分支，而不进行合并，开发人员维护分支的工作量就很大。34版本规划是项目经理（实际上是产品经理）的重要职责。版本规划决不是配置管理员所能作好的。35活动6： 配置审计和状态报告36配置审计的目的是，维护配置基线的完整性。配置审计由cm人员按照计划定期执行。配置审计在基线的重大变更前或者里程碑处进行随着项目的进展，审计工作频率和深度会逐步增加。37功能审计：确认基线配置项标识的正确性。验证基线的完备性。完备性是指该有的都有。验证基线的完整性。（完备性和一致性）验证基线产品内容的正确性。检查评审记录，确认评审中发现的问题确实在相应的文件中进行了修改。38物理审计：确认应受控配置项和基线的更改是受控的验证配置管理系统与系统备份的有效性和一致性验证配置管理活动与相应记录之间的一致性验证配置管理工作是否符合适用的标准和过程39 配置管理员审计前准备基线审计检查表 根据检查表进行审计 更新和完善配置项状态表 将审计结果记