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

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