SVN配置管理培训.ppt

1, 基本概念,配置管理培训,工程技术中心应用软件质控部,2,课程内容,配置管理的目的 配置管理的基本概念 配置管理的职责划分 配置管理的活动,3,配置管理目的,配置管理过程的目的是： 配置管理活动是有计划的 计划中要确定工作产品的基线 通过变更控制和配置审计来建立和维护工作产品的完整性。,4,配置管理的基本概念,CM：配置管理（Configuration Management）是指对项目生存期过程中的各阶段产品和最终产品演化和变更的管理。 CCB：变更控制组（Change Control Board）是配置项变更的监管组织。 配置项：指哪些应该纳入配置管理之下，成为受控的工作产品最小单位项。 基线：基线是经过正式评审和认可，作为后续工作依据的配置项集合。 配置审计：配置审计主要是验证配置项的完整性和配置项的一致性。,5,配置管理的职责划分,6,配置管理活动,活动1：制定配置管理计划及计划审批,7,配置管理计划内容： CCB组成 配置管理工具 配置库结构及访问权限 变更项的检入频率 配置项标识规则 识别出的配置项和基线 变更流程 配置审计和状态报告机制 配置库备份方案,8,CCB组成,CCB组一般由中层经理、项目经理、关键的开发人员、测试经理、配置管理员、质量保证人员和客户代表等有关人员组成。 CCB组长一般由中层经理担任，中层经理可授权给项目经理，但是中层经理要承担责任。,9,配置库结构,项目经理与配置管理员一起确定配置库结构。 一般情况下，配置管理库分为三个区： 开发区：供开发人员使用的配置区。 受控区：保存已被批准的配置项（包括基线）或项目统一管理的过程资产记录。 产品区：将通过系统测试后的产品作为最终产品存放，等待交付客户运行和现场测试。,10,开发区、受控区合二为一，通过标签来识别受控项 目录结构包括： 源程序 模块A 模块B 模块C 文档 需求、设计、手册、产品集成、测试、 各种计划、对外接口、其它 工具,标签由配置管理员 创建和维护,MACSV的控制器程序和SmartPro共用,11,配置库结构,产品区单独分开，存放在空间较大的服务器上。 产品区存放的内容包括： 安装盘 制作安装盘所用的工程 发布单及相关的发布资料 映像文件 安装文件 产品区由配置管理员管理与维护。,12,访问权限,配置服务器口令由配置管理员或指定人员掌握。 不同角色的人员对配置库的访问权限不同。 产品区只有CM人员有读写权，其他人只能查看。 受控区和开发区合二为一，其中的内容，根据需要分配权限。一般情况下，一个模块由一个人负责维护。,核心资产建一个单独的构件,一个项目的公共服务建一个构件,构件的内容： 需求、设计、代码、变更记录、构建脚本,13,配置项的粒度,一般情况下，建议配置管理控制的最小层次是： 程序模块文件或文档，也就是说，一个程序模块所包含的各个文件不单独进入配置管理的范围，只作为程序模块整体的一部分被增加、删除或更新。,14,配置项的粒度,例1：一个数据库创建脚本，由一个目录下的多个sql文件组成，这些sql文件被作为一个整体看待。 例2：将项目的需求库中的每个需求文档看作为一个配置项。,15,变更项的检入频率,对于基线产品，当发布基线和变更基线时必须将配置项检入； 对于非基线产品，在阶段结束时必须将配置项检入； 对于代码，建议一周至少要检入一次。,16,识别配置项,在配置管理计划中，要识别出项目可能的配置项 配置项“是什么”、“什么时候置于配置管理之下” 包含多个文件的配置项要定义“由什么组成” 可以使用一个说明性的readme文件或配置项清单文件来反映每个配置项所包含的内容,17,基线划分的原则,基线就是经过正式评审和认可的工作产品 它作为以后进一步开发的基础 只有通过正式的变更控制流程才能对它进行变更 如果控制要求严格，则定义多条基线 如果控制相对不太严格，则可只定义一条需求基线,18,常见基线,需求分析,软件设计,编码,测试,运行系统,测试计划、流程、测试数据,代码,设计,软件需求,客户需求,19,推荐的基线,20,配置管理活动计划,制定配置管理活动计划列表，明确执行配置管理活动的时间点,21,22,配置管理活动,活动2： 创建和维护配置库,23,创建和维护配置库,按照计划建立配置库，并分配相应的访问权限。,定期（至少每月一次）检查配置库的访问权限分配情况，及时收回无权限人员拥有的权限。,检查配置库，及时发现和纠正非法操作。,不定期变更配置库访问口令，以免口令的泄密。,及时删除不再需要的、废除的配置项。,24,配置管理活动,活动3： 发布基线和打标签,25,26,发布基线前一定要给相应的配置项的正确版本打标签，打完标签后，要把标签锁上，以防止他人对标签进行修改，避免造成混乱。 也可以对某些中间版本打标签。 创建标签时要说明标签的用途。,打标签,27,配置管理活动,活动4： 变更控制,28,非基线产品的变更由项目经理控制： 变更申请人提出变更请求，项目经理确认后即可对通知配置管理员开通权限，进行修改。 配置管理员开通权限，如果配置项升版，则需对原版本打标签。 变更实施人修改配置项时，应记录修改信息，修改完成后通知配置管理员收回权限。 添加或删除配置项时，应通知配置管理员。 配置管理员更新配置项状态清单。,变更控制,29,变更控制-流程图,基线产品的变更控制,CCB,QC验证人员,30,基线产品的变更： 变更申请人向项目经理提交变更申请表。 项目经理对变更申请进行初步审核后，提交给CCB评审。 CCB组织评估其影响，然后审批，指定变更实施人，并把配置变更申请表交给配置管理员。 配置管理员将批准的配置变更申请表纳入配置管理库 变更实施人员完成修改后，由指定的人员进行验证。 配置管理员更新基线，保证基线产品中的配置项均已被check in，锁定需要进行变更的基线及其产品，提升基线到变更状态（即，将基线版本升级）。 配置管理员填写配置项状态清单表，并将变更情况通知相关人员。,31,配置管理活动,活动5： 创建版本分支,32,创建版本分支,当一个新的功能版本衍生时，项目经理要写一个说明给配置管理员，说明要创建一个版本分支，创建分支的目的是什么，以主线上的哪个版本为基础创建分支，分支与主线的关系，以及将在什么时间点与主线合并，谁在分支上工作。,33,创建版本分支,不建议创建太多分支。 分支多会造成管理的混乱和困难。 分支多，合并的工作量就会很大。 如果建了很多分支，而不进行合并，开发人员维护分支的工作量就很大。,34,创建版本分支,版本规划是项目经理（实际上是产品经理）的重要职责。 版本规划决不是配置管理员所能作好的。,35,配置管理活动,活动6： 配置审计和状态报告,36,配置审计,配置审计的目的是，维护配置基线的完整性。 配置审计由CM人员按照计划定期执行。 配置审计在基线的重大变更前或者里程碑处进行 随着项目的进展，审计工作频率和深度会逐步增加。,37,配置审计,功能审计： 确认基线配置项标识的正确性。 验证基线的完备性。完备性是指该有的都有。 验证基线的完整性。（完备性和一致性） 验证基线产品内容的正确性。检查评审记录，确认评审中发现的问题确实在相应的文件中进行了修改。,38,配置审计,物理审计： 确认应受控配置项和基线的更改是受控的 验证配置管理系统与系统备份的有效性和一致性 验证配置管理活动与相应记录之间的一致性 验证配置管理工作是否符合适用的标准和过程,39,配置审计和状态报告,配置管理员审计前准备基线审计检查表 根据检查表进行审计 更新和完善配置项状态表 将审计结果记录于基线审计报告中 将配置项状态表和基线审计报告一并发送给项目经理、QA和项目相关人员。,40,41,42,配置管理活动,活动7： 配置库的备份,43,配置库的备份,定期备份配置库是保证项目资产安全的重要步骤 在配置管理计划中要规定备份的日程 需要备份的内容 频率 介质 保存期 存放地点,44,参考文件,配置管理过程 配置管理计划模板 变更申请表,45,Thank you !,