SCM软件配置管理
软件配置管理 软件配置管理 （Software Configuration Management， SCM） 问题引出 IEEE 定义 A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item， control changes to those characteristics， record and report change processing and implementation status， and verify compliance with specified requirements. 一套应用技术上和管理上的指导和监督的方法，用来：识别和记录配置项的功能特征和物理特征；控制这些特征的变更；记录和报告变更的处理和执行的状态，以及验证起是否符合特定的需求。 有那么一类管理 软件配置管理，是关于软件资产的管理。 软件 = 源代码 + 文档。 源代码、设计文档、可以运行的程序等在软件研发过程中产生的有价值的东西，都是软件资产。 图书管理 VS 软件管理 1、图书管理的事图书资产，软件配置管理管理的是软件资产。其实这两种管的都是信息资产。 2、图书管理，需要把图书进行分类，以便检索；需要将图书存放在合适的地方，以便存取。还要防止虫吃鼠咬。软件配置管理也类似，需要把软件资产放在合适的目录结构里。防止丢失或者错乱。 3、在图书馆，要记录图书的借阅情况，为了保证图书不丢失；在软件配置管理中也类似，需要记录哪位程序员借出了哪个文件，什么时候还。如果程序员修改了它，还需要记录下来这些修改。 4、图书需要更新，软件也需要更新。 为什么是配置管理 1、汽车配置：底盘（传动系、转向系、制动系和行驶系）、发动机、车身、电气设备 2、电脑配置：主板（内存、CPU、显卡）、硬盘、机箱、显示器、外设 3、手机配置：屏幕、CPU、GPU、内存、闪存、主板、按键 4、软件配置：代码、文档、安装程序、引用类库、资源文件 从机器的视角，每个零件都有型号、编号。很容易想到，应该有某种列表或者文档来表明各个零部件型号和组成关系（Bill of Material， BOM）。当配置有变动的时候，要跟新这样的清单。而且这样的变动不能随随便便的，应该先让总工程师批准，做相应的测试。 从软件的视角，软件也是配置起来的。各个源文件、源代码和正确的文档搭配起来，编译产生正确的可以运行的程序。 另外软件配置管理更有自己的特点： 1.软件更容易发生变化，是向前演进的。 2.软件的相关性（耦合）更高，一旦需要改动，通常不是只更改一个文件。 其他的比喻 结绳记事 攀岩岩钉 保险柜 脚印 …… 终定义 是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。 软件配置管理，又称软件形态管理、或软件建构管理，简称软件形管。界定软件的组成项目，对每个项目的变更进行管控（版本控制），并维护不同项目之间的版本关联，以使软件在开发过程中任一时间的内容都可以被追溯，包括某几个具有重要意义的数个组合。 在软件建立时变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱。SCM活动的目标是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为小并有效地提高生产效率。 从流程角度看，软件配置管理是整个软件开发生命周期中一个非常核心的管理过程。配置管理实际贯穿了从需求分析、架构设计、项目管理、开发、集成构建、测试以及上线的全过程。这一过程不仅涉及宏观的项目进度控制、配置管理规范及计划、多地点开发规划等，也包括更细粒度的分支模型、构建及集成方式、变更处理流程，还包括微观的与开发人员直接相关的版本控制、差异比较和归并等。 Version Control-版本控制 Change Control-变更控制 Process Support-过程支持 关键活动包括：配置项、版本库管理、版本控制、变更控制、状态报告、配置审计等。 术语解释 配置 “配置”是在技术文档中明确说明并终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，及其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素。 配置项 为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置管理的基础和前提。 配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待。 一个系统包括的配置项的数目是一个与设计密切相关的问题。 · 文档：一篇文档是一个配置项 · 代码：推荐将整个项目组的所有代码当做一个配置项。如果项目组内不同模块之间的进度相差很大的时候，将每一个模块的代码划分为一个配置项更加方便管理。 基线 在配置管理系统中，基线是配置项在其生命周期的不同时间点上通过评审而进入正式受控的一种状态，而这个过程被称为“基线化”。 每一个基线都是其下一步开发的基准。 基线具有以下属性： · 通过正式的评审过程建立。 · 基线存在于配置库中，基线的变更由变更控制委员会（CCB-Change Control Board）控制。 · 基线是进一步开发和修改的基准。 版本 版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。 版本以版本号进行标识。 · 版本号 Version Number：为简略的表达特定版本的目的和意义，为方便区分不同的版本，我们需要版本号这个概念。又称作版本标识。 · 版本库：也叫存储库，Repository。在版本库里，存储源代码的各个版本。当然存储的是不同版本见有差异的部分，增量存储。 · 签入：检入，check in. 代码修改完了以后，需要告知版本控制工具，将新的代码保存到版本库中。 · 签出：检出，chekc out。代码修改前，需要先告知版本控制工具，讲版本库中的代码复制到本地。 玄妙的学院派 配置计划 配置管理计划是开展所有配置管理活动的基础。 计划中应该明确以下要素： · 配置管理人员的组织和职责 · 配置项的命名规则 · 配置管理工具以及配置库结构 · 标识的配置项和位置 · 权限分配和管理方法 · 配置库备份的周期、方法 · 变更控制的流程和操作方法 · 版本发布的计划和策略 · 基线审计计划 · 集成策略 · 软件配置管理的场景 配置标识 Configuration Identification 是配置管理的一个组成部分，包括：选择产品的配置项、为他们制定的标识，并在技术文档中记录其功能和屋里的特性。 配置标识是对软件配置进行管理的前提和基础。配置标识包括了软件配置项的选择、划分和对配置项的功能物理属性进行描述的过程。 每个配置项都必需被地标识，这个的标识被用于与其它配置项进行区分，跟踪和报告该配置项的状态。一般地，每个配置项被赋予一个标识符。 · 文档：对所有文档而言，文件名作为配置项的命名 · 代码：使用“项目名-模块名＋代码”或者“项目名＋代码”的方式进行命名 · 工具：以工具本身的名称命名 定义配置项的版本 单个配置项在每一次修改后都会发生变化，为了标识配置项在两次修改之间的不同，需要对配置项的版本进行标识。 配置项版本命名原则 配置项的版本标识建议采用的形式为：xx.yy的十进制标识符，其中xx起始为“1”，yy起始为“0”。 所有数字均是阿拉伯数字，并且单调递增。如果发生了重大的修改，xx递增；如果只有小修改，递增yy。 已基线化 成为基线的配置项是指已完成该配置项的审核、批准和签发并且成为创建或修改其他配置项的输入。 受管理和受控的 受管理和受控的配置项是指已提交审核，但还没有批准通过的配置项。 配置控制 Configuration Control 是配置管理的一个组成部分，包含评估、协调、批准/拒绝、实施对配置项的变更。 这发生在正式的配置标识之后。 配置控制包括配置项在完成基线化后所产生的变更的评估、协调、批准、驳回以及实现过程。 · 变更请求的管理 · 变更的协调工作 在项目开始时，由项目负责人根据项目的情况确定变更控制委员会（Change Control Board， CCB），并记录在配置管理计划中。CCB组长也可以根据更改请求的情况事件驱动地召集CCB会议。CCB也可以批量处理更改请求或采用定期的方式进行处理。 如有必要，可以设立不同级别的CCB，他们具有不同的授权，对不同层次的变更申请进行控制根据修改的影响范围，CCB召开相应的评估会议，并邀请相关人员参加 配置状态报告 Configuration Status Report 是配置管理的一个组成部分，记录和报告用来有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单，变更请求当前的处理状态，以及一品准的变更的实现情况。 配置状态报告是跟踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报给项目组和相关组成员。 一旦配置项基线化后，应该通知项目组， 内容应该包括基线化配置项的名称以及位置。另外应该周期或事件驱动地将更新后的培植状态发给项目组成员以及相关组，以确保配置项的状态能被相关人员所了解，根据需要一周或者两周发布一次 · 版本库相关的信息：名字、存储位置、编号、管理员、主要用途描述 · 版本库中产品的相关信息 · 文件相关的信息 · 变更请求、基线、发布、版本库的备份等 配置审计 Configuration Audit 执行审计以验证配置项符合特定的标准或需求 对配置管理的独立的查检过程，确认受控软件配置项满足需求并绪。 · 功能审计：配置项的变更控制是否和配置管理计划中的描述相一致 · 物理审计：配置项的完整性、正确性， 一致性和可跟踪性 软件配置管理的组织 角色 · 项目经理 PM: Project Manager 制定和修改项目的组织结构和配置管理策略； 批准、发布配置管理计划； 决定项目起始基线和开发里程碑； 接受并审阅配置控制委员会的报告。 · 变更控制委员会 CCB: Change Control Board 负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。其具体职责为以下几项： 定制开发子系统； 定制访问控制； 制定常用策略； 建立、更改基线的设置，审核变更申请； 根据配置管理员的报告决定相应的对策。 · 软件配置工程师 CMO: Configuration Management Officer 根据配置管理计划执行各项管理任务，定期向CCB提交报告，并列席CCB的例会。其具体职责为以下几项： 软件配置管理工具的日常管理与维护； 提交配置管理计划； 各配置项的管理与维护； 执行版本控制和变更控制方案； 完成配置审计并提交报告； 对开发人员进行相关的培训； 识别软件开发过程中存在的问题并拟解决方案。
