1. 配置管理岗位职责
- 范围：组织级和项目级配置管理
- 管理对象为过程和产品，产品为识别出的配置项
- 建立配置库：为项目建立开发库（管理库）、基线库，建立配置库结构并分配权限（命名规范）
- 基线管理，在每个阶段结束的时候，按配置管理计划建立基线库，以及变更基线
- 版本管理，使用配置工具git进行版本管理，以及文档修订记录
- 配置库备份，收权限
- 编制配置管理计划，依据软件项目过程定义、项目计划、配置管理规程、过程资产库编制配置管理计划
- 配置审计，包括功能设计和物理审计
- 记录CM活动，撰写配置管理周期性工作报告
- 为项目组提供SCM 理论和相关工具的培训，并提供技术支持
2. 基于CMMI配置管理体系结构
在CMMI2.0中对配置管理又有新的诠释和变化，例如：去掉了配置状态记录，重点强调了配置控制的方法，将配置控制明确为版本控制和变更控制。再如：对基线的阐述不仅仅有软件基线，2.0也新增了硬件基线，这给软硬件一体项目实施的组织提供了理论基础。
如何验证您正在使用和遵循这些流程？
我可以阅读，配置管理规则，命名规程，配置管理计划等规范，同时，QA会对我的配置管理工作进行审计，EPG和项目经理对我的工作检查。
如何评价对于过程的遵循度和过程的有效性？
QA会从过程和产品两个方面对我的工作进行检查，一般按项目阶段及配置管理计划进行检查；
EPG评估过程的有效性。
3. 配置项分级别、分类管理及标识：
3.1. 配置项分级别
按管理的严格程度，配置项一般分2个等级：
（1）基线配置项
- 所有设计文档和源程序等【重要】
- 基线配置项向开发人员开放读取和权限
（2）非基线配置项
- 项目各类计划和报告等
- 非基线配置项向PM、CCB及相关人员开放
另外参考，按管理的严格程度，配置项一般分3个等级：
（1）纳入基线管理的配置项
纳入基线管理的配置项是指变化时要走严格变更手续的配置项，需要做变更申请，要审批。审批一般分2种严格程度：
i) 项目经理或分CCB审批就可以，一般是局部的小的变更。
ii）变更控制委员会（CCB）审批
纳入基线前，一般要经过评审或测试（称为验证）和质量保证。
（2）没有纳入基线但是也不能随意变更的配置项，一般称为受控项
这类配置项不需要变更申请，但是要经过配置管理员或项目经理的允许才可以变更。
基线项与受控项写的权限要唯一，一般是CM或PM有唯一的写权限。
（3）非受控项
对变更不做控制。
3.2. 配置项分类
凡是纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类：
- 一类是属于产品的组成部分，例如需求文档、设计文档、源代码、测试用例等；
- 另一类是在管理过程中产生的文档，例如各种计划、报告。
3.3. 配置项标识
配置项标识是描述在项目软件管理过程的配置管理活动中如何对文件夹、文件名进行命名以及识别和标识配置项。
例如：配置项命名规范
- 配置项：公司简称—项目简称—文件名—编号
- 基线：项目简称——基线名—编号
4. 项目实践
4.1. 配置管理计划
职责定义，包括配置管理员、QA、项目经理、CCB组长、CCB成员。
配置库为gitlab
配置管理过程：
- 配置库计划，包括权限表、库目录结构
- 基线计划，包括基线名称、配置项、计划时间
- 配置审计计划，包括审计时间、审计内容
- 备份与恢复计划
状态报告，确定所有与配置管理相关的记录、生成频率，编写人及接收人。
配置管理计划维护，当需求或项目计划变更时，由配置管理员维护配置管理计划，并提交项目经理批准。
4.2. 基线及基线变更
| 序号 | 基线名称 | 版本号 |
|---|---|---|
| 1 | 需求基线 | V1.0 |
| 1.1 | 需求基线 | V1.1 |
| 2 | 设计基线 | V1.0 |
| 3 | 测试基线 | V1.0 |
| 3.1 | 测试基线 | V1.1 |
| 4 | 发布基线 | V1.0 |
如何重新生成基线？
4.3. 配置审计
CM进行功能审计和物理审计,主要是在基线建立和基线变更时进行审计。
- 物理配置审计是用以验证所构建的配置项符合技术⽂档中对其的定义和描述，内容主要看配置项是否按计划正确入库、申请与发布是否一致，以及发布位置、版本、命名等基本信息是否正确。
- 功能审计：主要是检查文件内容是否符合需求，符合模板。
4.4. 变更申请
变更申请由（需求、发布）申请变更和基线变更申请两部组成。
首先，是发起修改申请，从配置库签出文档和源代码；
其次，是发起配置项入库变更申请，从开发库签入到基线库。
例如，申请需求变更时，如何管理文档和源代码的变更？
1.需求基线检出：依据审批通过的需求变更申请，我先把相关文档从基线签出到开发库中，再由项目经理基于签出的文档组织修改变更；
2.需求基线变更CCB审批：需求变更需要重新生成需求基线，对于需要纳入需求的基线的文档，需经过评审，由需求开发者向CCB提出需求基线变更申请，CCB审批通过；
3. 需求产品重建基线：
产品入库检查，协助QA进行功能审计，并进行物理审计；
产品入库，使用Git工具提交生成基线；
发布基线，发布需求变更基线，我（CM）通知相关人员已完成变更。
4.5. 配置项登记表
5. 总结
配置管理工作范围，包括组织级配置管理和项目级配置管理。
配置管理活动覆盖了整个软件生命周期，也覆盖了生命周期中所有的工作产品，所以这个活动会涉及很多的干系人，配置管理主要活动有：配置管理计划、基线管理、变更管理、配置库管理、版本管理、配置审计。
从另一个维度来说，配置管理就是识别配置项、管理配置项，通过技术或其他手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。
6. 附件，Gitlab操作补充
6.1. 增加项目成员
6.2. 修改项目成员权限
6.3. gitlab备份与恢复
基于CentOS 下搭建Gitlab+Gitlab-runner，实现如下功能：
- 每日整体备份；
- 备份保存30天；
- 备份数据恢复测试；
具体安装、配置详解《 gitlab备份与恢复》。
参考：
肖永威. CMMI2.0配置管理工作及访谈学习笔记. CSDN博客. 2022.12
麦哲思科技任甲林. 配置项管理的3个等级. CSDN博客. 2009.12
xiaodaiwang. gitlab备份与恢复. CSDN博客. 2022.10
