25 配置管理
软件系统产品的配置管理活动包括
| 名称 | 描述 |
|---|---|
| 变更管理 | 跟踪来自客户和开发者的软件变更请求，计算做出这些变更的花费并估计其影响，决定是否变更、何时完成变更 |
| 版本管理 | 跟踪系统组件的多个版本，确保由不同开发者对组件做出的变更不会彼此干涉 |
| 系统构建 | 一个组装程序组件、数据和库的过程，然后把这些组件编译链接成一个可执行系统 |
| 发布管理 | 包括准备对外发布的软件，持续跟踪已经发布以供客户使用的系统版本 |
| 配置管理术语 | 解释 |
|---|---|
| 配置项或软件配置项(SCI) | 与配置管理控制下的软件项目有关的人格事物(设计、代码、测试数据、文档等)。配置项会存在多个不同的版本。每个配置项有唯一的名字 |
| 配置控制 | 确保系统和组件的版本得到记录和维护的过程。这样变更可以得到管理，所有的组件的版本都能在整个系统生命周期中识别和存储 |
| 版本 | 配置项的一个实例，区别于其他配置项的实例。版本总是有一个唯一标识符，通常由配置项名字加上版本号组成 |
| 基线 | 用于组成系统的组件版本的集合。基线是受控的，意味着构成系统的组件的版本是不能改变的，总是可以从它的组成组件中重新创建一个基线 |
| 代码线 | 是软件组件以及组件所依赖的其他配置项的集合 |
| 主线 | 代表系统不同版本的基线的序列 |
| 发布版本 | 发布给客户(或其他机构中用户)使用的系统版本 |
| 工作空间 | 一个私有的工作空间，在其中软件可以修改而不至于影响其他会使用或修改软件的开发者 |
| 分支 | 从现存的代码线的版本中创建一个新的代码线。然后新的代码线和已存在的代码线可独立开发 |
| 合并 | 通过合并在不同代码线中的单独版本创建软件组件的新版本。这些代码线可能是由某个代码线的先前存在的分支所创建的 |
| 系统构建 | 通过耦合和链接组件和库的适当版本创建一个可执行的系统版本 |
25.1 变更管理
- 变更管理过程
- 提交变更请求：客户(非开发团队)完成并提交一个描述对系统的变更的变更请求
- 变更请求可能是描述错误症状的错误报告，也可能是增加系统附加功能的请求
- 变更请求：可通过填写变更请求表(CRF)来提交
- 变更请求表包含的内容：提议、估算成本、请求、核准、实现和有效性验证日期、开发人员实现变更的概述
- 检查变更请求：检查以确保是否有效
- 检查者可来自客户、应用支持团队或开发团队的一个成员(内部请求时)
- 评估和成本估算：处理有效的变更请求
- 通常是开发团队或维护团队的任务
- 开发团队检查所有因变更而受到影响的组件
- 评估系统请求变更的模块
- 产品开发小组或变更控制委员会估算实现成本以及其他系统组件可能要相应发生变更的成本
- 决定是否同意变更请求时需要考虑的因素
- 不做变更会引起的后果
- 变更的益处：哪些用户收益
- 变更影响的用户数：影响用户越多，优先级越低，甚至不可取
- 变更所需花费
- 产品发布循环：刚发布版本，可推迟需求到下一个版本
- 影响到单个组件或模块的变更，不需要单独评估，可直接交给开发团队
- 实现变更：开发团队变更软件组件时，应维护每个组件的变更记录，也成为组建的导出历史
- 最佳方式是将其放在组件源代码开头的标准化的注释部分
- 注释应该索引到引起系统变更的请求
- 每个版本的变更记录经常放到一个独立页中，一般放在文档的前面
25.2 版本管理
- 版本管理(VM, version management)：跟踪软件组件或配置信息以及使用这些组件系统的不同版本的过程
- 版本管理确保由不同开发者做出的变更不会彼此影响
- 版本管理过程可看做是管理代码线和基线的过程
- 版本管理系统的特征
| 特征 | 描述 | 优点 |
|---|---|---|
| 版本和发布版本识别 | 被管理版本提交给系统时给它们分配标识符。标识符通常基于配置项的名字，后跟一位或几位数字 | 简化了定义配置的问题，是快速索引更简单 |
| 存储管理 | 版本管理系统通常会提供存储管理工具。系统只存储每个版本不同之处的列表而不是每个版本的副本 | 减少了只有轻微差异的不同版本所占存储空间。通过把版本的不同之处列表应用到源版本(通常是最近的版本)，就能够重建目标版本 |
| 变更历史记录 | 记录并列出所有对系统或组件做出的变更 | 在一些系统中，这些变更可以用来选择一个特殊的系统版本 |
| 独立开发 | 不同的开发者可能在同一时间正在相同的组件上工作 | 版本管理系统跟踪检出的组件，确保不同开发者对组件做出的变更不会彼此影响 |
| 项目支持 | 一个版本管理系统可能支持共享组件的几个项目的开发 | —— |
25.3 系统构建
- 系统构建是把软件组织、外部的库、配置文件等编译和链接成一个完整的、可执行的程序的过程
- 构建过程可能有三种不同的系统平台
- 开发系统：包括开发工具，比如编译器、源码编译器等
- 开发系统对应的是私有工作空间
- 开发人员将代码从版本管理系统下载到私有空间，再做修改
- 构建服务器：用于构建确定的、可执行的系统版本
- 构建服务器和版本管理系统紧密交互
- 系统构建可能依赖外部库，但这些库未包含在版本管理系统
- 目标环境：对应目标平台，是系统运行的平台
- 可能是和用于开发和构建系统相同类型的电脑
- 构建系统的特征
| 特征 | 描述 |
|---|---|
| 构建脚本生成 | 在必要情况下，构建系统应该分析待构建的程序，识别依赖的组件，并自动生成一个构建脚本(有时叫配置文件)。系统也应支持手工创建和编辑构建脚本 |
| 版本管理系统集成 | 构建系统应从版本管理系统中检出需要的组件版本 |
| 最小化再编译 | 构建系统应分析出哪些源代码需要进行再编译，再对需要的代码进行编译 |
| 可执行系统创建 | 构建系统应将编译后的各个目标代码文件以及其他需要的文件(如库文件、配置文件等)链接起来，创建可执行的系统 |
| 测试自动化 | 有的构建系统能使用自动化工具，如 JUnit，自动运行自动测试。可以检查构建是否被变更破坏 |
| 报告 | 构建系统应提供关于运行的构建或测试成功与否的报告 |
| 文档生成 | 构建系统可能能生成关于构建和系统帮助页面的版本注释 |
- 持续集成的步骤
| 步骤 | 描述 |
|---|---|
| 检出主线 | 将主线系统从版本管理系统中检出到开发人员的私有工作空间 |
| 构建和测试系统 | 构建系统并允许自动测试，以确保所构建的系统能通过所有测试。不能则构建终止。这时应通知最后提交主线系统的开发人员。他们负责修复这个问题 |
| 做相应变更 | 完成系统组件的变更 |
| 构建和测试系统 | 在私有工作空间构建系统并重新运行测试。测试失败则继续编辑 |
| 检入到构建服务器 | 系统通过测试，将它检入到构建系统，但是不要作为新系统基线提交 |
| 构建和测试系统 | 在构建服务器上构建系统并运行测试。如果有人修改了组件，检出失败的组件并进行编辑，使测试在私有工作空间通过 |
| 加入版本管理系统 | 如果系统在构建系统上通过测试，将作出的变更作为系统主线中的一个新的系统基线 |
25.4 发布版本管理
- 系统的发布版本：分发给客户的版本
- 主要发布：交付重要的新功能
- 小型发布：修复漏洞和用户报告的问题
- 发布版本应包括
- 系统的可执行代码
- 配置文件：定义对于特定安装，发布版本应该如何配置
- 数据文件：比如错误信息的文件，是成功进行系统操作必需的
- 安装程序：用来帮助在目标硬件上安装系统
- 电子和书面文档：用于系统说明
- 包装和相关的宣传：为发布版本所做的工作