SVN配置管理

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