老铁们，大家好，相信还有很多朋友对于配置管理流程和的相关问题不太懂，没关系，今天就由我来为大家分享分享配置管理流程以及的问题，文章篇幅可能偏长，希望可以帮助到大家，下面一起来看看吧！
1.2 缩写和略语
序列号
名词
阐明
1
配置项CI
是指包含在配置管理范围内的工作成果，如需求文档、设计文档、源代码、测试用例等属于产品一部分的工作成果，以及项目管理和组织支持生成的文档过程区域。
2
基线基线
它由一组相对稳定的配置项组成，通常对应于开发过程中的里程碑。
3
配置管理员CMO
每个项目分配一名配置管理员，负责为该项目制定《配置管理计划》，创建和维护配置数据库，并及时出具配置状态报告、配置项变更申请表等报告。
4
变更控制委员会CCB
虚拟团队可以由EPG成员、项目经理、高级项目成员、配置经理、QA等组成。项目经理是CCB的召集人； CCB 对各种配置管理活动（例如审核计划、审核变更请求等）拥有决策权。
5
基线库
项目存储配置项及相关配置管理记录的仓库
6
配置管理系统
由基线库以及用于访问该基线库的工具和过程组成。
1.3 过程总体概述
配置管理流程整体图如下：
1.4 相关文件
l 《项目跟踪与监控流程》
l 《项目计划模板》
2 过程活动描述
2.1 制定配置管理计划CMP
1. 目的
项目前期根据项目计划制定项目配置管理计划，方便项目有计划地开展配置管理工作。
2. 角色和职责
角色
职责
配置管理员
制定《配置管理计划》
建行
评论《配置管理计划》
专案经理
建立基线标准
3. 进入条件
l 《项目计划书》已制定
l 配置管理员和CCB已确定
4. 输入
l 《项目计划书》
5. 任务描述
1. 调研项目配置管理需求
确定配置管理的软件和硬件资源
公司采用统一的服务器作为配置管理服务器，采用统一的软件作为配置管理软件。
2. 识别配置项
配置管理员必须根据《项目计划书》识别主要配置项，并唯一标识配置项。
配置项标识符：
配置项由“项目名称缩写_文件类别_其他”标识。
例如：JXC40-CODE-CG（进销存、销售和库存4.0产品源代码-采购模块）。
配置项标识符应该具有一定的含义，能够描述其所代表的文件、源代码的内容或功能。配置项标识可以是英文或中文，但必须是唯一的。
3. 制定基线计划
配置管理员确定每个基线的名称（标识符）及其包含的主要配置项，并根据项目经理提供的基线标准估算每个配置项受控的时间和建立基线的时间。
基线ID：
项目的生命周期一般有四个基线：需求基线、设计基线、编码基线和产品基线。基线由“项目名称缩写_基线名称缩写_基线版本号”标识。
例如：JXC40_RB_1（进销存、销售和库存4.0 需求基准的第一个版本）。
配置项和基线计划的格式如下：
配置项ID
配置项名称
所属基线
存储相对路径
计划基准日期
实际基准日期
CI001
合同
需求基线
4. 制定配置数据库的备份计划
配置管理员制定配置数据库备份计划，指定“谁”和“何时”（频率）将配置数据库备份到“哪里”。 （参见2.2.5.3 备份管理）
5. 制定额外的配置管理计划
1）配置管理库的结构以及各级人员对配置库的读取权限的定义。
2) 配置管理审核计划。
3）基线发布和外部发布计划。
6. 审核《配置管理计划》
建议让建行审核《配置管理计划》。如果审核通过，CMO将根据CMP执行配置管理任务。
7.《配置管理计划》 包含在配置库中
配置管理员将批准的《配置管理计划》纳入配置库。
6. 输出
l 《配置管理计划》
7. 退出条件
l 《配置管理计划》已制定并审核通过
2.2 创建配置库（项目文件夹）
1. 目的
对配置库活动进行统一控制和管理，确保配置项的完整性和可追溯性，包括：建立项目文件夹、划分配置库区域和备份管理。
2. 角色和职责
角色
职责
配置管理员
负责项目文件夹的创建、配置管理系统的管理和控制
建行
审查并批准基线的建立和变更
3. 进入条件
l 《配置管理计划》已制定并审核通过
l 配置管理的软硬件已经具备
4. 输入
l 《配置管理计划》
5. 任务描述
a) 建立配置库（项目文件夹）
l 根据配置管理计划的要求，建立项目的配置管理环境，包括配置服务器和相应的网络环境。
l 使用配置管理计划中确定的配置管理工具建立项目的配置管理体系。
l 配置管理员根据《配置管理计划》中配置库的目录结构建立基线区域的目录结构。配置库的目录结构可以根据选择的配置管理工具建立，参见《配置库目录结构指南》。
b) 配置项受控
l 配置项及其所属基线在《配置管理计划》的“配置项计划”中标识。
l 根据《配置管理计划》中“配置项”的“计划控制时间（一般在配置项审核通过后）”，将受控时间点的配置项及时纳入基线区域。
l 在【配置状态报告】中标识每个配置项的负责人（也称为配置项的所有者）。
c) 建立基线
l 需要建立基线时，项目经理应提交基线建立申请。基线申请通常在阶段或里程碑点结束之前提出；
l CCB对基线建立申请进行审核，确保组成基线的配置项一致、完整、正确；当CCB审核通过基线建立申请后，配置管理员执行基线建立操作。
l 配置管理员在建立基线之前应将所有管理文档存储在数据库中。基线建立申请中只能列出工程产品。通过“配置审核”可以检查管理文档是否正确存储在数据库中。
l 配置管理员针对实际的基线建立结果生成【基线建立通知】，发送给相关人员，并存入数据库。
l 根据所使用的配置管理工具和实际情况，可以采用不同的方法来建立基线：
1）文件夹：直接将基线包含的配置项检出到文件夹中保存。该文件夹及其内容可以被视为基线。
2）标签：有些配置管理工具可以给每个配置项打上相同名称的标签，通过这个标签可以查看到所有的配置项。使用这样的工具，建立基线的一种方法是用相同的名称标记每个配置项。对于不具备此功能的配置管理工具，可以在建立基线时在项目的根路径上打上标签，以保证可以返回到建立基线时的配置库状态，并识别其中包含的具体配置。必要时设定基线。配置项可以通过基线建立通知中的记录来实现。
d) 备份管理
l 备份目的：当系统发生灾难时，保证系统能够恢复到备份前的状态。
l 备份内容：包括配置库中的所有内容，以及开发环境、工具等支持工具。
l 备份检查：根据实际情况定期检查备份情况。
配置数据库备份包括定期备份和灾难备份：
1.定期备份
根据项目需要在《配置管理计划》中指定定期备份策略、时间、介质、备份记录、标记方式、存储要求等。配置管理员应按照《配置管理计划》规定的定期备份要求进行备份，填写备份记录（在【配置状态报告】中），并对备份进行标记。
l 定期备份策略
l 指示是否备份所有文件、仅备份最新版本或定期执行增量备份。
l 时间要求
l 根据项目规模和时间安排确定定期备份的时间间隔。一般可以每周一次、两周一次、每月一次等。
l 备份介质
l 备份介质需要CDR/CDRW/MO/磁带或其他设备的硬盘等。
l 备份记录
l 备份时，配置管理员填写备份记录（在【配置状态报告】中）。
l 为备份添加标签
l 根据配置项的命名标准对备份进行标记，例如：
l JXC40-代码-CG_Backup_1.0 200602
l 存储要求
l 备份应存放在安全的地方，防潮、防磁、防曝晒、防挤压，以免备份损坏。
2、灾难备份
是指为防止地震、火灾、洪水等灾害给工程造成损失而采取的备用措施。该措施要求将项目备份介质存放在公司办公楼以外的地方，以便灾后系统能够恢复。
灾难备份不是以项目为单位进行，而是以服务器为单位进行，由服务器管理员负责定期实施。实施时，首先填写灾难备份详细信息（在【配置状态报告】中），并将备份内容提交给组织级配置管理员，由组织级配置管理员将其发送到公司指定办公楼外的安全地点进行存储。
一旦发生灾难，组织级配置管理员从安全位置获取备份，并将其交给服务器管理员，由服务器管理员负责恢复工作。
灾难备份策略、时间、介质、备份记录、标记方式、存储要求等与常规备份相同。但由于灾难备份存储在公司外部，因此需要采取安全保密措施，例如对备份的外包装进行加密、密封等。
6. 输出
【基线建立通知】
备份记录（在【配置状态报告】中）
7. 退出条件
项目结束
2.3 配置项变更控制
1. 目的
为了防止配置项被随意修改而造成混乱，本变更控制主要针对基线文档。
2. 角色和职责
角色
职责
审批人员（含CCB）
审查变更申请并指定变更执行人
配置管理员
执行出站/入站操作
项目成员（变更执行人）
执行变更任务
3. 进入条件
l 需要更改的配置项已基线化
4. 输入
l 需要更改的配置项
5. 任务描述
1.申请变更
变更申请人向CMO提交变更申请（填写《配置项变更申请表》相关内容），重点说明“变更内容”和“变更原因”以及“配置项变更对项目的影响”。 CMO按照《变更审批权限规定》《项目计划书》（见附件01）向相应审批人员提交变更申请。
2. 审核变更申请
审批者审查申请并分析变更对项目的影响。
3.安排变更任务
项目经理指定变更执行者并安排他们的任务。项目经理需要与变更执行者就变更内容达成共识。
4. 执行变更任务
a) 变更执行者根据项目经理分配的任务修改配置项。一般要求对文档类的更改需要填写更改记录（在文档目录之前以及使用配置管理工具签入时需要输入的注释）。
b) 项目经理监督变更任务的执行，如检查变更内容是否正确、工作是否按时完成等。
5. 重新评估
如果配置项是技术文件，则需要经过技术审查。如果配置项是“规划”等重要管理文件，则需要CCB及相关人员审核。
6、将更改的配置项合并到配置库中
当所有变更的配置项都通过审核后，配置管理员将通过审核后的配置项进行基线操作。建行签约《配置项变更申请表》。配置管理员将《配置项变更申请表》 保存在CMO 工作区中。
7. 配置状态通知
CMO将使用《配置项变更通知单》通知项目团队和CCB成员配置项的变更；
6. 退出条件
l 变更项目包含在基线中，变更结束。
2.4 配置审计
1. 目的
通过审核配置管理库中的每个配置项、基线和配置管理相关记录和活动，验证配置管理活动执行的正确性，确认配置管理库中的配置项是否正确，以及检查基线的一致性和完整性。
2. 角色和职责
角色
职责
配置管理员
根据配置管理计划定期执行配置审核活动（包括基线审核）
3. 进入条件
l 配置管理计划制定的审核时间；
l 阶段结束前，检查基线的完整性，跟踪不一致的情况；
4. 输入
l 审计配置项
l 配置审核清单
5. 任务描述
配置管理员对配置管理库的状态进行审计，确定配置库中各配置项以及建立的基线的正确性和完整性，并记录审计结果。配置审核的频率取决于项目，但至少应该在建立基线之前和发布之前进行。
配置审核包括：
l 配置库系统是否满足实际需求
l 配置库系统是否正常运行，提供正确版本的功能？
l 备份内容是否可恢复
l 工作产品签出后是否当天签入
l 每个基线库签入动作是否有注释
l 基线库签入的注释是否使用Label来标识重要版本
l 上次审核中发现的问题是否全部解决？
l 每个阶段的基线完整性和一致性检查
具体检查实施项目参见【配置审计检查清单】。
6. 输出
l 【配置审核清单】发现和审核记录不一致
7. 退出条件
l 审计不一致问题已解决
2.5 产品发布
1. 目的
产品发布活动的目的是确保进入测试阶段或提交给客户的最终产品的正确性和完整性。
2. 角色和职责
角色
职责
配置管理员
根据配置管理计划执行编译的产品版本
3. 进入条件
l 产品已达到验收标准
4. 输入
l 经过内部验证测试的产品
5. 任务描述
产品发布包括内部发布和外部发布，向客户发布产品。
内部发布主要是用于内部测试或备份的产品发布。步骤如下：
l 项目经理提交基线发布请求
l 配置管理员执行编译并对编译成功的产品进行基线
l 配置管理员/项目经理从产品基线检查产品
外部发布是产品最终发布给客户的，比内部发布需要更严格的控制。步骤如下：
l 项目经理或营销人员提交产品发布申请
l 测试人员从基线区域的产品基线（产品目录）中检测产品并进行测试（参见已测试
流程描述），主要用于发布确认测试。
l 配置管理员将正式发布测试产品
l 相关部门人员根据客户要求制作交付媒体的产品
l QA根据《项目计划书》中的“2.2里程碑和可交付成果”进行产品放行检查
l 相关部门人员向客户发布产品
6. 输出
l 已通过测试的最终产品
7. 退出条件
l 产品通过测试或发布给客户
2.6 配置状态报告
1. 目的
记录和报告配置管理活动、配置项的状态和历史记录，以确保所有配置项的内容和状态被确定和已知，并且每个版本都是可追溯的。说明配置项变更的原因、变更的范围，以及最新版本、版本号、各个版本的比较。
2. 角色和职责
角色
职责
配置管理员
记录和识别配置项状态和历史版本，并发布配置状态报告。发生变更后，发出【配置项变更通知】
3. 进入条件
l 基线建立后
l 配置项变更后
l 配置审计结果
l CM阶段报告模板（频率与项目管理一致）
4. 输入
l 基线建立通知[基线建立通知表])
l 配置项变更控制
5. 任务描述
通过[基线建立通知]、[配置项变更通知]和[配置状态报告]报告配置状态。
l 配置审计报告
在该阶段结束之前，CMO执行配置审核，报告审核结果，并跟踪不一致的解决情况；
l 【基线建立通知】
基线下的所有配置项均受控。基线对应的阶段计划结束时，CMO与项目经理和CCB确认后，发出基线建立通知书；
l 【配置项变更通知单】
变更者提交【配置项变更申请表】后，配置项变更申请通过，变更审核通过后，CMO予以放行；
l 【配置状态报告】
当配置项受到控制、配置项发生更改、建立基线以及执行配置审核时，会发布配置状态报告。
作用：保持项目开发过程的一致性，让开发人员及时了解各个配置项的当前状态和变化。
l 【CM舞台报告】
注：每个阶段结束时，CMO将根据【CM阶段报告】报告本阶段的工作进展。
6. 输出
l 配置状态报告
l CM阶段报告
7. 退出条件
l 项目结束
3 裁剪指南
如果备份不是在项目基础上执行而是在服务器基础上执行，则项目团队可以定制备份管理活动。
4 度量与验证
4.1 度量
测量项目名称
评论
入住/退房及时率
分支状态/合并周期
配置项缺失率
配置管理计划中列出的配置项与配置库中包含的配置项的比较
配置变更管理工作
因果比——例如，30% 的配置更改没有更改请求，反映了更改管理的强度
变更周期
配置项变更影响范围
通过RTM 追踪影响
功能审计的一致性证据
4.2 验证
验证方法
验证方法
验证关键点
验证时机
配置管理员
审计
现场实物审核
[配置审核清单] 列出的合规项目
根据配置管理计划执行定期配置审核活动（建立基线时）
质量保证验证
会议沟通讨论
电子邮件通讯
检查上述活动的执行情况并填写检查表
参加必要的审查会议
接收每个工作产品
5 工作产品一览
l 《配置管理计划》
l 【配置状态报告】的配置项列表、配置项控制计划、基线计划
l 【配置管理计划清单】
l 【基线建立通知】
l 【配置项变更申请表】
l 【配置项变更通知单】
l 【配置状态报告】（包括配置项状态内容）
l 【配置审核清单】
l 【CM舞台报告】
6 附录
l 附录01 变更审批机关规定参考
项目背景：
V4模型项目中，本地开发了财务管理业务类型。项目经理与客户就变更控制达成如下共识：变更审批权限：
病情描述
审批人员
工作量
其他条件
专案经理
（姓名）
部门经理
（姓名）
建设银行会员
（姓名）
单次变更工作量小于等于4人时或累计变更工作量小于24人时。
单次变更工作量小于等于8人时或累计变更工作量小于36人时。
单次变更工作量大于8人时或累计变更工作量小于48人时
原创文章，作者：小su，如若转载，请注明出处：https://www.sudun.com/ask/186205.html
用户评论
微信名字
终于有人写了关于配置管理流程的文章！这在我公司一直都是个问题，大家总是搞得混乱不堪。希望这篇能给我们一些启发啊。
有8位网友表示赞同！
■□丶一切都无所谓
配置管理流程确实很重要，它能确保系统稳定高效运作。之前我公司就因为缺乏规范的管理流程导致很多部署出错，简直一团糟。<br>
有16位网友表示赞同！
一生荒唐
我感觉这个主题有点枯燥啊…配置管理流程太专业了，大部分普通人可能不太理解吧？
有7位网友表示赞同！
罪歌
配置管理流程确实可以提高效率和安全性，但如果过于复杂化反而会适得其反。 找一个既规范又灵活的方案太难了！
有6位网友表示赞同！
惯例
我公司现在用的配置管理工具还好，但是流程设计的的确不太完善，导致很多重复工作。看了这篇希望能学习到一些新的想法。
有11位网友表示赞同！
面瘫脸
这篇文章写的很详细，把各个环节都解释清楚了。希望能早点在我们的项目中应用！
有7位网友表示赞同！
巷口酒肆
我只想说一句话：配置管理流程太重要啦！如果你的系统比较复杂，那就更要重视它了，否则后果不堪设想！
有18位网友表示赞同！
ヅ她的身影若隐若现
我一直觉得软件开发应该更加灵活，强调快速迭代。复杂的配置管理流程反而会阻碍进度。
有15位网友表示赞同！
不识爱人心
对IT新人来说，了解配置管理流程非常重要！它可以帮助你更好地理解系统的运行机制，也更容易在团队中找到自己的位置。
有13位网友表示赞同！
西瓜贩子
我公司之前完全没有配置管理的意识，导致各种版本混乱问题频发。现在终于重视起来，希望能快速建立起一套完善的流程。
有11位网友表示赞同！
反正是我
这篇文章对我很有帮助，我已经开始在我们的项目中尝试实施部分建议了。希望它能够为我们带来实质性的提升！
有10位网友表示赞同！
淡写薰衣草的香
配置管理可不是一件容易的事情，需要不断地探索和改进才能找到最适合自己的方案。
有18位网友表示赞同！
长裙绿衣
我感觉配置管理流程就像生活中的一套生活规则，没有固定的模式，但要有条理和目标才能更好地执行。
有18位网友表示赞同！
寻鱼水之欢
配置管理真的太重要了！不仅关系到系统稳定性，还影响着团队的效率和协作。希望更多人重视它！
有13位网友表示赞同！
晨与橙与城
这篇文章让我想起了之前我们公司遇到的很多系统维护问题，都是因为缺乏有效的配置管理导致的！看来以后我得多关注这个方面了。
有13位网友表示赞同！
伱德柔情是我的痛。
配置管理流程确实可以让工作更加规范，但也要适度灵活，避免过于僵化。
有14位网友表示赞同！
愁杀
这篇文章把我吸引住了，我之前对配置管理还一知半解，这篇内容解释得很清晰，让我初步了解了它的重要性！
有14位网友表示赞同！
仰望幸福
这个主题太深入了！我只想说：希望配置管理流程可以像美食一样让人享受到美味的体验！
有16位网友表示赞同！