软件配置管理培训(1)

如何表达版本的质量状态
❖ 在版本号中，添加状态标记（常用方法）。有两个 弱点：1.在版本库中，标签不一定能重新命名。 2. 改变标签名称，以及改变安装包的名称，可能会引 起混乱。
❖ 版本本身可以自带些属性。当质量状态提升时，不 必改版本名称，只需改版本的质量状态属性。
❖ 用不同的目录，来区分不同质量状态下源代码的整 体版本或安装包。
❖ 主线始终是开发的主流。
主线
短分支经常集成
主线
A—1
B—1
A
B
长期隔离导致集成困难
A—2
B—2
A—3
B—3
为特定用户，进行单独立项， 进行特定开发的解决方法。
❖ 改变版本结构，要集中精力在主线演进， 集中精力开发一个产品，从主线出发，有 每个分支上，主要关注用户的特殊需求。
鲢
鲈
魭
鲑
鲟
鲫
鲆
鳝
鲤
❖ 加强对公共组件的变更管理。 ❖ 为公共组件的开发提供环境支持。 ❖ 共享多个系统中对公共组件的修改。 ❖ 应对多个系统的系统总体集成中的问题。
避免变体的方法
❖ 聪明的拒接个别客户提出的要求。 ❖ 在标准版本里，实现客户的要求。 ❖ 安装软件时，特定用户只安装特定的组件。 ❖ 通过软件运行时的配置、设置，实现不同外
基本的版本控制
假设每个程序员负责一个专门模块，不存 在两个程序员修改同一处源代码的问题。
❖ 在修改程序之前，从哪里拿到最新版本？
（程序员可能基于过时的程序开始自己的工作）
❖ 在修改程序之后，把修改结果提交到那？
（程序员的工作可能被湮没）
解决之道
将源代码流转的渠道从 网状结构（图1）改成星 星结构（图2），也就是 设立一个公共储区，作为 参照物和枢纽，大家统一 从这个公共点取代码，的 轩昂程序改完后，都把自 己改的那部分全部传到公 共存储区，别人再从那里 取用。
❖ 自动化
❖ 提高硬件性能
❖ 提高专一性（尽量减少在同
一台服务器上同时运行的构建任务 单元的数量）
❖ 生产过程是固定明确的
（或是尽可能的文档化构建过程）
❖ 把构建任务分解，并行
完成（要实现分布式构建，其软
件实现难度则大了很多，可能需要 一些 通常是必要的，因为这样可以在需要它的时 候能够迅速准确的得到这个安装包。
❖ 什么是系统集成 ❖ 系统集成的步骤
系统集成
系统集成，简称集成，是基本的使命就是把 产品的各个部分捏在一起，并保证产品作为 整体是可以运转的，而不仅是每个模块，每 个单元能在特定的开发调试环境、特定的数 据和参数下运转。
❖ 视角1：集成的，不是模块，而是工作。每个任务 单元可能在一个模块上修改，也可能涉及多个模块。
❖ 取出要集成的源代码。（最好放在一个全新的工作空间）
❖ 编译、链接和打安装包。（通常称为构建）
❖ 安装并粗略测试。
如有问题，修改了源代码，
❖ 表示和储备集成成果。
就从头再来。
（集成结果有两个：1.源代码的整体版本 2.生成安装包）
❖ 通知相关人员本次集成完成。
（还应告知集成成员的名称和存储内容）
❖ 软件配置管理 ❖ 基本的版本控制 ❖ 系统集成 ❖ 构建管理 ❖ 分支 ❖ 变体 ❖ 三库管理的概念
使用分支 ❖ 能有效的实现隔离，也实现共享。
弱势： ❖ 分支是有管理成本的。如果变体所在的分支
上，包含了一些应该共享的改动，那么应合 并到主干上。这样的话，相应管理成本也会 提高。
支持分支的多种方法
使用文件属性
❖ 在一定程度上实现了隔离，但并不完全。在 降低共享的成本同时，削弱了隔离。
❖ 共享又不总是能够自动传播。需要手动修改 其他变体的相关文件，才能实现这个功能改 动。
❖ 软件配置管理 ❖ 基本的版本控制 ❖ 系统集成 ❖ 构建管理 ❖ 分支 ❖ 变体 ❖ 三库管理的概念
❖ 什么是分支 ❖ 分支与工作空间的对比 ❖流 ❖ 集中精力于主线的演进 ❖ 分支管理要注意的事项
分支
❖ 主线又被称为主干，是一种特殊的分支。 ❖ 合并是某种复制行为，不是复制版本本身，而是复
❖ 视角2：不再把产品的各个模块合到一起，而是把 产品的改变合到一起，和在已有的版本上，产生新 的版本，所集成的是任何单元，是变更。
多层集成
源代码整体版本
新的整体版本
+=
多个任务单元
集成的含义
集成的步骤
❖ 确保开发人员都提交了相关的源代码。
❖ 冻结或者标识将要集成的源代码。
（比如：禁止开发人员向版本库的提交）
—— 一个权威定义 （被CMM、CMMI引用）
软件配置管理的一些比喻
❖ 图书管理 （在一借一还的过程中都需要记录） ❖ 保险柜 （软件资产可能丢失、被窃取和泄露，特别是源代码） ❖ 岩钉 （适当保存历史版本，所有的一切软件资产都可以保存）
缺乏管理所造成的问题
❖ 软件开发人员之间缺乏必要的交流 ❖ 产品升级和维护所必需的程序和文档非常混乱 ❖ 开发过程中的人员流动经常发生 ❖ 因管理不善致使未经测试的软件加入到产品中 ❖ 项目开发状态不清楚 ❖ 软件生产达不到规模化
❖ 什么是构建管理 ❖ 构建管理分为两部分 ❖ 保证构建的可重复性 ❖ 如何让构建更快 ❖ 安装包有没有必要保存 ❖ 安装包如何保存
构建管理
❖ 构建：从源代码生产出安装包的过程。 ❖ 一般包括：编译源代码；链接编译结果；产
生可以运行的程序；把所有对客户有用的东 西都打包。 ❖ 构建的输入，是产品的全部源文件，可能还 有文档、数据等。 ❖ 构建的输出，通常是安装包。
弱 势：
❖ 分支不能改变其起始点，工作空间可以改变
兼具分支和工作空间的优势 流
流的三种含义
❖ 流是起始点可改变的产品级的“分支”。 ❖ 流的起始点可以设置为产品的某个整体版本。 ❖ 流可以设置为另外的某个流的末端。
❖ 分支不能长期存在，把分支缩短，在每一次 组内集成，就合并到主线，并关闭该分支， 重新建立新的分支，来吸收下一次组内集成 的内容。
支持分支的多种方法
使用不同的Makefile ❖ 与使用文件属性一样，在一定程度上实现隔
离，共享又不总是能够自动传播。 ❖ 比使用文件属性好的地方是，程序员能够同
时看到不同变体所需的源文件。
（要注意对Makefile本身的维护）
支持分支的多种方法
使用宏定义
❖ 宏和Makefile的方法差不多，都是有选择的 选择源代码进行编译，不同的是：Makefile 只能区分到文件夹；宏可以区分到源文件。
❖ 基线是有质量状态的。当探测到源代码质量状态到 达了更新程度的时候，做一个基线提升。
基线 ❖ 被明显的标记和记录下来的源代码整体版本。
（即整体复制） ❖ 在每个文件的特定版本上打标签来完成。
基线的权限——只读
❖ 软件配置管理 ❖ 基本的版本控制 ❖ 系统集成 ❖ 构建管理 ❖ 分支 ❖ 变体 ❖ 三库管理的概念
图1 图2
假设两个程序员同时修改同一源代码，会出 现程序覆盖问题。（即后提交的代码B会把先 提交的代码A覆盖）
❖ 监控。阻止同
时修改的事情发 生。串行方法
❖ 辅助。使同时
修改的内容合并 到一起。并行方法
串行方法
并行方法
❖ 版本控制软件还可以对程序修改进行有效的 管理，将开发环境、测试环境、运行环境进 行有效的隔离。我们还可以在版本控制软件 中存放软件开发过程中成成的各种文档，以 供随时查阅。
❖ 什么是变体 ❖ 产生变体的原因 ❖ 用分支支持变体 ❖ 支持分支的多种方法
（组件复用）
❖ 避免变体的方法 ❖ 减少变体的成本
变体
变体是指一些软件产品，他们彼此有些相 同之处，但彼此有有所区别。
产生变体的原因： ❖ 因支持不同操作系统而产生的变体。 ❖ 因客户制定而成的变体。 ❖ 因不同的功能集而产生变体。
鳗
鲐
鲂
鱼的裂变
主线 1.0版
鲢
鲑
鲈
2.0版
魭
鲟
鳝
鲫
鲆
3.0版
鲤
鲂
鳗
鲐
主线产鱼法
分支管理要注意的事项
❖ 每条分支的目的和用途，必须明确，并且分 支要有合适的名字。
❖ 分支要规划确定相关角色和权限，要注意全 盘考虑，看版本树的整体图景。
❖ 软件配置管理 ❖ 基本的版本控制 ❖ 系统集成 ❖ 构建管理 ❖ 分支 ❖ 变体 ❖ 三库管理的概念
支持分支的多种方法
完全独立开发 ❖ 可以有效的保证遍体之间的隔离，但是无法
支持变体之间的共享。
常用的改进方法： ❖ 从某一点开始，独立出来，从此分道扬镳。在这一
点之前，所积累的软件资产，就变成变体之间共享 了。但随后的改动，只能通过手工的方法，在不同 的变体或变体与主流间传播。
支持分支的多种方法
制版本之间的差异。合并不会影响原分支的。
分支与工作空间的对比
优势：
❖ 分支可同时容纳多个已提交的任务单元，并以此和其他分 之区别。
❖ 分支存储在服务器上比工作空间存储在本地安全。 ❖ 分支是所有人都能看到，若有必要，所有人都能在上边工
作；工作空间是单个开发人员自己的地盘 ，只有自己才能 在上面工作。
❖ 如果将它删除，在将来需要它的时候，还要 找历史上的源代码，现从源代码开始编译、 打包，那么会耗费时间。
安装包如何保存？
❖ 放进版本库不是明智之举。对于安装包，很 多历史版本，比如送去测试用的安装包，需 要定期清理，否则会占用大量的磁盘空间。 安装包可以保存在共享目录下，该目录可以 在局域网共享，除此之外，还要考虑适当的 备份。
用分支支持变体
❖ 假定，基于标准版1.0版，开发
1.0—A版。这是为客户A专门制 主线
定的一个版本，里边增加了了一