—— 一个权威定义 （被CMM、CMMI引用）
软件配置管理的一些比喻
❖ 图书管理 （在一借一还的过程中都需要记录） ❖ 保险柜 （软件资产可能丢失、被窃取和泄露，特别是源代码） ❖ 岩钉 （适当保存历史版本，所有的一切软件资产都可以保存）
缺乏管理所造成的问题
❖ 软件开发人员之间缺乏必要的交流 ❖ 产品升级和维护所必需的程序和文档非常混乱 ❖ 开发过程中的人员流动经常发生 ❖ 因管理不善致使未经测试的软件加入到产品中 ❖ 项目开发状态不清楚 ❖ 软件生产达不到规模化
基线 ❖ 被明显的标记和记录下来的源代码整体版本。（即整体复制） ❖ 在每个文件的特定版本上打标签来完成。
基线的权限——只读
❖ 软件配置管理 ❖ 基本的版本控制 ❖ 系统集成 ❖ 构建管理 ❖ 分支 ❖ 变体 ❖ 三库管理的概念
பைடு நூலகம்
❖ 什么是系统集成 ❖ 系统集成的步骤
系统集成
系统集成，简称集成，是基本的使命就是把产品的各个部分捏在一起，并保证产品作为整体是可以运转的， 而不仅是每个模块，每个单元能在特定的开发调试环境、特定的数据和参数下运转。
❖ 软件配置管理 ❖ 基本的版本控制 ❖ 系统集成 ❖ 构建管理 ❖ 分支 ❖ 变体 ❖ 三库管理的概念
❖ 基本的版本控制 ❖ 基线
版本管理，主要是建立一个公共存储区，记录版本，防止版本覆盖，防止版本混乱。 版本管理是配置管理里重要的一项环节。
❖ 在软件开发中会遇到一些非常棘手的问题，比如，需要将整个软件版本恢复到以前的某一时间的状态； 控制某个程序在同一时间只能被一个程序员修改等等。这时就需要使用版本控制软件进行管理了。版本 控制软件可以将某一程序恢复到以前的某一时间的状态，甚至将整个软件版本恢复到以前的某一时间的 状态。也能够实现某一程序在同一时间只能一个开发人员修改，还可以配制成允许多人修改，最后将不 同版本合并为新版本。
如有问题，修改了源代码，就从 头再来。
❖ 软件配置管理 ❖ 基本的版本控制 ❖ 系统集成 ❖ 构建管理 ❖ 分支 ❖ 变体 ❖ 三库管理的概念
❖ 什么是构建管理 ❖ 构建管理分为两部分 ❖ 保证构建的可重复性 ❖ 如何让构建更快 ❖ 安装包有没有必要保存 ❖ 安装包如何保存
构建管理
❖ 构建：从源代码生产出安装包的过程。 ❖ 一般包括：编译源代码；链接编译结果；产生可以运行的程序；把所有对客户有用的东西都打包。 ❖ 构建的输入，是产品的全部源文件，可能还有文档、数据等。 ❖ 构建的输出，通常是安装包。
（或是尽可能的文档化构建过程）
如何让构建更快
❖ 自动化 ❖ 提高硬件性能 ❖ 提高专一性（尽量减少在同一台服务器上同时
运行的构建任务单元的数量）
❖ 把构建任务分解，并行完成（要实现分布式构 建，其软件实现难度则大了很多，可能需要一 些高端软件的支持）
基本的版本控制
假设每个程序员负责一个专门模块，不存在两个程序员修改同一处源代码的问题。 ❖ 在修改程序之前，从哪里拿到最新版本？ （程序员可能基于过时的程序开始自己的工作） ❖ 在修改程序之后，把修改结果提交到那？ （程序员的工作可能被湮没）
解决之道
将源代码流转的渠道从网状结构（图1）改成星星结构（图 2），也就是设立一个公共储区，作为参照物和枢纽，大家 统一从这个公共点取代码，的轩昂程序改完后，都把自己 改的那部分全部传到公共存储区，别人再从那里取用。
图1 图2
假设两个程序员同时修改同一源代码，会出现程序覆盖问题。（即后提交的代码B会把先提交的代码A覆 盖）
❖ 监控。阻止同时修改的事情发生。 串行方法
❖ 辅助。使同时修改的内容合并到 一起。并行方法
串行方法
并行方法
❖ 版本控制软件还可以对程序修改进行有效的管理，将开发环境、测试环境、运行环境进行有效的隔离。 我们还可以在版本控制软件中存放软件开发过程中成成的各种文档，以供随时查阅。
软件配置管理培训
❖ 软件配置管理 ❖ 基本的版本控制 ❖ 系统集成 ❖ 构建管理 ❖ 分支 ❖ 变体 ❖ 三库管理的概念
❖ 什么是软件配置管理 ❖ 软件配置管理的一些比喻 ❖ 缺乏管理所造成的问题
什么是软件配置管理
一套应用技术上和管理上的指导和监督方法，用来：识别和记录配置项的功能特征和物理特征；控制 这些特征的变更；记录和报告变更的处理和执行的状态；以及验证其是否特定的需求。
构建分为
全量构建
增量构建
❖ 是从每一个源文件的编译开始，不借助于以往 构建中留下的已有的或许可以重复使用的结果。 （通常系统集成，集成工程师所做的构建是全 量构建)
❖ 是尽可能的利用上次构建的成果。 是一个省时间偷懒的方法）
（这
正确、准确
快速
保证构建的可重复性 ❖ 原材料是固定明确的 ❖ 工具是固定明确的 ❖ 参数设置是固定明确的 ❖ 生产过程是固定明确的
如何表达版本的质量状态
❖ 在版本号中，添加状态标记（常用方法）。有两个弱点：1.在版本库中，标签不一定能重新命名。 2. 改变标签名称，以及改变安装包的名称，可能会引起混乱。
❖ 版本本身可以自带些属性。当质量状态提升时，不必改版本名称，只需改版本的质量状态属性。 ❖ 用不同的目录，来区分不同质量状态下源代码的整体版本或安装包。 ❖ 基线是有质量状态的。当探测到源代码质量状态到达了更新程度的时候，做一个基线提升。
❖ 冻结或者标识将要集成的源代码。
（比如：禁止开发人员向版本库的提交）
❖ 取出要集成的源代码。（最好放在一个全新的工作空间）
❖ 编译、链接和打安装包。（通常称为构建）
❖ 安装并粗略测试。
❖ 表示和储备集成成果。 装包）
（集成结果有两个：1.源代码的整体版本 2.生成安
❖ 通知相关人员本次集成完成。
（还应告知集成成员的名称和存储内容）
❖ 视角1：集成的，不是模块，而是工作。每个任务单元可能在一个模块上修改，也可能涉及多个模块。
❖ 视角2：不再把产品的各个模块合到一起，而是把产品的改变合到一起，和在已有的版本上，产生新的 版本，所集成的是任何单元，是变更。
多层集成
源代码整体版本
新的整体版本
+
=
多个任务单元
集成的含义
集成的步骤
❖ 确保开发人员都提交了相关的源代码。