软件配置管理内部培训(三库、集成)

构建管理
构建：从源代码生产出安装包的过程。 一般包括：编译源代码；链接编译结果；产 生可以运行的程序；把所有对客户有用的东 西都打包。 构建的输入，是产品的全部源文件，可能还 有文档、数据等。 构建的输出，通常是安装包。

构建分为
全量构建

增量构建

是从每一个源文件的编 译开始，不借助于以往 构建中留下的已有的或 许可以重复使用的结果。
图1
图2
假设两个程序员同时修改同一源代码，会出 现程序覆盖问题。（即后提交的代码B会把先 提交的代码A覆盖）

监控。阻止同
时修改的事情发 生。串行方法

辅助。使同时
修改的内容合并 到一起。并行方法
串行方法 并行方法

版本控制软件还可以对程序修改进行有效的 管理，将开发环境、测试环境、运行环境进 行有效的隔离。我们还可以在版本控制软件 中存放软件开发过程中成成的各种文档，以 供随时查阅。
使用分支 能有效的实现隔离，也实现共享。 弱势： 分支是有管理成本的。如果变体所在的分支 上，包含了一些应该共享的改动，那么应合 并到主干上。这样的话，相应管理成本也会 提高。
支持分支的多种方法
使用文件属性

在一定程度上实现了隔离，但并不完全。在 降低共享的成本同时，削弱了隔离。 共享又不总是能够自动传播。需要手动修改 其他变体的相关文件，才能实现这个功能改 动。
弱点： 宏是写在源代码里，遍体多的话，结构就会 复杂，难以维护。 并非所有编程语言都支持宏。
支持分支的多种方法
组件复用 把系统分解为组件，系统由不同的组件构成， 每个组件，可能多次参与不同系统的构成。

组件有三种：源代码组件、运行组件、库组件。
组件复用
引用组件复用后，软件配臵管理还要额外关 注的事情。 加强对公共组件的变更管理。 为公共组件的开发提供环境支持。 共享多个系统中对公共组件的修改。 应对多个系统的系统总体集成中的问题。
2.0版
支持分支的多种方法
完全独立开发 可以有效的保证遍体之间的隔离，但是无法 支持变体之间的共享。

常用的改进方法： 从某一点开始，独立出来，从此分道扬镳。在这一 点之前，所积累的软件资产，就变成变体之间共享 了。但随后的改动，只能通过手工的方法，在不同 的变体或变体与主流间传播。
支持分支的多种方法
主线始终是开发的主流。

主线 短分支经常集成 主线
A—1
B—1
A
B
长期隔离导致集成困难
A—2
B—2
A—3
B—3
为特定用户，进行单独立项， 进行特定开发的解决方法。

改变版本结构，要集中精力在主线演进， 集中精力开发一个产品，从主线出发，有 每个分支上，主要关注用户的特殊需求。
主线 1.0版 鲢 鲢 鲈 鲈 鲫 鲤 鳗 鲂 魭 鲑 鲟 鲟 鳝 鲆 鲐 鲫 3.0版 鳝 鲆 2.0版 鲑 魭
软件配 置管理
——康子烨
软件配置管理 基本的版本控制 系统集成 构建管理 分支 变体 三库管理的概念
什么是软件配臵管理 软件配臵管理的一些比喻 缺乏管理所造成的问题
什么是软件配置管理
一套应用技术上和管理上的指导和监督 方法，用来：识别和记录配臵项的功能特征 和物理特征；控制这些特征的变更；记录和 报告变更的处理和执行的状态；以及验证其 是否特定的需求。
（通常系统集成，集成工程师所 做的构建是全量构建)
是尽可能的利用上次构 建的成果。
（这是一个省时间偷懒的方法）
正确、准确
快速
保证构建的可重复性

如何让构建更快

原材料是固定明确的

工具是固定明确的
参数设置是固定明确的
自动化 提高硬件性能 提高专一性（尽量减少在同
一台服务器上同时运行的构建任务 单元的数量）


视角1：集成的，不是模块，而是工作。每个任务 单元可能在一个模块上修改，也可能涉及多个模块。 视角2：不再把产品的各个模块合到一起，而是把 产品的改变合到一起，和在已有的版本上，产生新 的版本，所集成的是任何单元，是变更。
源代码整体版本 新的整体版本
+
=
多个任务单元
集成的含义
多层集成
集成的步骤
如何表达版本的质量状态




在版本号中，添加状态标记（常用方法）。有两个 弱点：1.在版本库中，标签不一定能重新命名。 2. 改变标签名称，以及改变安装包的名称，可能会引 起混乱。 版本本身可以自带些属性。当质量状态提升时，不 必改版本名称，只需改版本的质量状态属性。 用不同的目录，来区分不同质量状态下源代码的整 体版本或安装包。 基线是有质量状态的。当探测到源代码质量状态到 达了更新程度的时候，做一个基线提升。

支持分支的多种方法
使用不同的Makefile

与使用文件属性一样，在一定程度上实现隔 离，共享又不总是能够自动传播。 比使用文件属性好的地方是，程序员能够同 时看到不同变体所需的源文件。
（要注意对Makefile本身的维护）

支持分支的多种方法
使用宏定义

宏和Makefile的方法差不多，都是有选择的 选择源代码进行编译，不同的是：Makefile 只能区分到文件夹；宏可以区分到源文件。
弱 势：

分支不能改变其起始点，工作空间可以改变
兼具分支和工作空间的优势 流
流的三种含义 流是起始点可改变的产品级的“分支”。 流的起始点可以设臵为产品的某个整体版本。 流可以设臵为另外的某个流的末端。

百度文库

分支不能长期存在，把分支缩短，在每一次 组内集成，就合并到主线，并关闭该分支， 重新建立新的分支，来吸收下一次组内集成 的内容。
什么是分支
分支与工作空间的对比
流 集中精力于主线的演进 分支管理要注意的事项
分支

主线又被称为主干，是一种特殊的分支。 合并是某种复制行为，不是复制版本本身，而是复 制版本之间的差异。合并不会影响原分支的。
分支与工作空间的对比
优势：


分支可同时容纳多个已提交的任务单元，并以此和其他分 之区别。 分支存储在服务器上比工作空间存储在本地安全。 分支是所有人都能看到，若有必要，所有人都能在上边工 作；工作空间是单个开发人员自己的地盘 ，只有自己才能 在上面工作。

通知相关人员本次集成完成。
（还应告知集成成员的名称和存储内容）
软件配置管理 基本的版本控制 系统集成 构建管理 分支 变体 三库管理的概念
什么是构建管理 构建管理分为两部分 保证构建的可重复性 如何让构建更快
安装包有没有必要保存
安装包如何保存

不把主线上的内容合并到分支 上，而是创建新的分支，把原 有分支上的内容复制过来。 （对于分支合并引入的代码修 改进行浏览和审查就会容易得 多。）
主线
1.0版 1.0—A 1.0—A版


弱势： 2.0—A 如果需要频繁的拿到标准版最 新版本里的内容，那么需要建 2.0—A版 很多分支。 如果变体与标准版的差距较大，提升变体版本（方法 二） 对应的源代码修改也很大。
鲤 鳗
鲂 鲐
鱼的裂变
主线产鱼法
分支管理要注意的事项

每条分支的目的和用途，必须明确，并且分 支要有合适的名字。 分支要规划确定相关角色和权限，要注意全 盘考虑，看版本树的整体图景。

软件配置管理 基本的版本控制 系统集成 构建管理 分支 变体 三库管理的概念
什么是变体
产生变体的原因 用分支支持变体 支持分支的多种方法 （组件复用） 避免变体的方法
减少变体的成本
变体
变体是指一些软件产品，他们彼此有些相 同之处，但彼此有有所区别。
产生变体的原因：
因支持不同操作系统而产生的变体。 因客户制定而成的变体。 因不同的功能集而产生变体。

用分支支持变体
软件配置管理 基本的版本控制 系统集成 构建管理 分支 变体 三库管理的概念
基本的版本控制 基线
版本管理，主要是建立一个公共存储区，记 录版本，防止版本覆盖，防止版本混乱。 版本管理是配臵管理里重要的一项环节。

在软件开发中会遇到一些非常棘手的问题，比如， 需要将整个软件版本恢复到以前的某一时间的状态； 控制某个程序在同一时间只能被一个程序员修改等 等。这时就需要使用版本控制软件进行管理了。版 本控制软件可以将某一程序恢复到以前的某一时间 的状态，甚至将整个软件版本恢复到以前的某一时 间的状态。也能够实现某一程序在同一时间只能一 个开发人员修改，还可以配制成允许多人修改，最 后将不同版本合并为新版本。
基本的版本控制
假设每个程序员负责一个专门模块，不存 在两个程序员修改同一处源代码的问题。

在修改程序之前，从哪里拿到最新版本？
（程序员可能基于过时的程序开始自己的工作）

在修改程序之后，把修改结果提交到那？
（程序员的工作可能被湮没）
解决之道
将源代码流转的渠道从 网状结构（图1）改成星 星结构（图2），也就是 设立一个公共储区，作为 参照物和枢纽，大家统一 从这个公共点取代码，的 轩昂程序改完后，都把自 己改的那部分全部传到公 共存储区，别人再从那里 取用。
确保开发人员都提交了相关的源代码。 冻结或者标识将要集成的源代码。

（比如：禁止开发人员向版本库的提交）
取出要集成的源代码。（最好放在一个全新的工作空间） 编译、链接和打安装包。（通常称为构建） 安装并粗略测试。 如有问题，修改了源代码， 就从头再来。 表示和储备集成成果。

（集成结果有两个：1.源代码的整体版本 2.生成安装包）

避免变体的方法
聪明的拒接个别客户提出的要求。 在标准版本里，实现客户的要求。 安装软件时，特定用户只安装特定的组件。 通过软件运行时的配臵、设臵，实现不同外 观和功能等。
—— 一个权威定义 （被CMM、CMMI引用）
软件配置管理的一些比喻
图书管理 （在一借一还的过程中都需要记录） 保险柜 （软件资产可能丢失、被窃取和泄露，特别是源代码） 岩钉 （适当保存历史版本，所有的一切软件资产都可以保存）

缺乏管理所造成的问题


软件开发人员之间缺乏必要的交流 产品升级和维护所必需的程序和文档非常混乱 开发过程中的人员流动经常发生 因管理不善致使未经测试的软件加入到产品中 项目开发状态不清楚 软件生产达不到规模化
基线

被明显的标记和记录下来的源代码整体版本。 （即整体复制） 在每个文件的特定版本上打标签来完成。 基线的权限——只读

软件配置管理 基本的版本控制 系统集成 构建管理 分支 变体 三库管理的概念
什么是系统集成 系统集成的步骤
系统集成
系统集成，简称集成，是基本的使命就是把 产品的各个部分捏在一起，并保证产品作为 整体是可以运转的，而不仅是每个模块，每 个单元能在特定的开发调试环境、特定的数 据和参数下运转。

安装包如何保存？

放进版本库不是明智之举。对于安装包，很 多历史版本，比如送去测试用的安装包，需 要定期清理，否则会占用大量的磁盘空间。 安装包可以保存在共享目录下，该目录可以 在局域网共享，除此之外，还要考虑适当的 备份。
软件配置管理 基本的版本控制 系统集成 构建管理 分支 变体 三库管理的概念

假定，基于标准版1.0版，开发 1.0—A版。这是为客户A专门制 定的一个版本，里边增加了了一 个只有客户A才需要的功能：点 石成金。 假定，在推出标准版2.0版后，客 户A请求将1.0—A版升级到2.0—A 版。既保留点石成金功能的同时， 去掉1.0版里发现的缺陷，添上2.0 标准版里新增加的功能。这时候怎 么处理？


生产过程是固定明确的
（或是尽可能的文档化构建过程）
把构建任务分解，并行 完成（要实现分布式构建，其软
件实现难度则大了很多，可能需要 一些高端软件的支持）
安装包有没有必要保存？

通常是必要的，因为这样可以在需要它的时 候能够迅速准确的得到这个安装包。 如果将它删除，在将来需要它的时候，还要 找历史上的源代码，现从源代码开始编译、 打包，那么会耗费时间。
主线 1.0版 1.0—A 1.0—A版

变体（简单情况）
用分支支持变体

把主线上所有的修改都复 制到分支上，集成测试， 并作适当调整，确保不影 响分支上的特殊功能。
主线
1.0版
A
1.0—A版
弱势: 可能引入的代码修改太多， 很难做到这一点。
2.0版
2.0—A版
提升变体版本（方法 一）
用分支支持变体