记录督促学习30

**二十五章

配置管理，主要是介绍软件配置管理过程和工具。
1了解软件变更管理的过程和规程
2了解版本管理系统必须提供的重要功能以及版本管理和系统构建之间的关系
3了解系统版本和系统发布的区别，了解发布管理过程的各个阶段。

在开发和使用过程中软件系统常常会变更，必须发现错误并加以修正，系统需求变更后，开发者不得不在新版本中实现这些变更，有了新版本的硬件和系统平台之后，开发者不得不使自己的系统与之兼容。

配置管理（CM）与管理变更软件系统的政策、过程和工具有关。
进化中的系统之所以需要管理，是因为系统在进化时会产生许多不同的版本，这些版本包含了变更提议、错误修正以及对不同硬件和操作系统的适应等诸多内容。
配置管理对个人项目管理来说非常有用，因为开发者容易忘记已做过的变更，对于几个开发者同时完成一个软件系统的团队项目配置管理也是必要的。

配置管理系统的使用确保了团队能够获得正在开发系统的信息而不妨碍彼此的工作。

软件系统产品的配置管理包括4个紧密相关的活动：
1变更管理
2版本管理
3系统构建
4发布管理
配置管理包括处理海量信息和许多为了支持配置管理而开发的配置管理工具。
配置管理政策和过程规定了如何记录和处理所提议的系统变更，如何决定需要变更的系统组件，如何管理系统的不同版本以及其组件，如何向客户发布变更。

有时配置管理被视为广义的软件质量管理过程的一部分。

配置管理标准的定义和使用对IOS900、CMM以及CMMI标准的质量认证时至关重要的。

配置管理的难题之一是不同公司使用不同的术语称呼相同的概念，这是由历史原因的，军用软件系统可能是第一个使用配置管理的系统，这些系统术语反映了已经存在的硬件配置管理的过程和流程。

变更对大型软件系统而言是一种无法更改的事实，在系统的整个生命周期内机构的需要和需求发生改变，错误需要修正 ，系统需要适应变化了的环境，为了确保变更以一种可控制的方式应用在系统中，开发者需要一系列工具的支持和变更管理程序。
变更管理确保系统的进展是一个可管理的过程，并且最紧急和费效最优的变更拥有最高的优先权。

变更管理过程主要关心的是对所提议的变更的成本收益分析，保证变更是值得去做的，并且记录系统哪些组件已经改变。

客户和变更： 敏捷方法强调在变更优先权选择过程中客户参与的重要性，客户代表帮助团队决定在下个开发循环中需要实现的变更，尽管这对于像哪些为单个客户开发的系统来说是有效的，它对于那些没有真正客户与团队一起工作的产品是有问题的，在这种情况下，团队需要自己决定变更的优先权顺序。

变更请求提交后，需要进行检查以确保是否有效。检查者可以来自于客户、应用支持团队或者是开发团队的一个成员。

对于有效的变更请求，变更管理过程的下一个阶段就是对变更进行评估的成本估算，这通常是开发团队或者维护团队的任务，因为他们能够计算出完成变更所需的成本。变更对系统其它部分带来的影响必须注意审查，因此开发者必须检查所有因变更而受到影响的组件。

变更控制委员或是产品开发小组应从战略的、机构的角度，而不应从技术角度去考察变更带来的影响。
决定是否同意变更请求时需要考虑的重要因素：
1不做变更会引起的后果
2变更的益处
3变更影响的用户数
4变更所需花费
5产品发布循环

对软件产品的变更管理比为特定客户开发的软件系统的变更管理额处理上稍有不同。
对软件产品，客户并不直接参与进来，所以变更与客户业务的相关性不是问题，这些产品中的变更请求来自客户支持团队，公司市场营销团队和开发团队自身，这些需求可能反映来自客户的建议和反馈，或者是由竞争产品提供的分析。

客户支持团队提交的变更请求可能与软件发布后由客户发现并报告的错误相联系。
开发期间，当系统的新版本通过每日的系统构建创建以后，就可以采用较为简单的变更管理过程。
在一些敏捷方法中，比如极限编程中，客户直接参与决定是否实现变更。当他们对系统需求提出变更时，他们与项目组成员一起评估变更产生的影响。然后决定这个变更是否应该优先于为系统下一个增量所规划的特征。
当开发团队变更软件组件时，他们应该维护每个组件的变更记录，有时把这陈伟组件的导出历史。

变更管理由专门的软件工具支持。这些可能是相对简单的基于网页的工具，比如Bugzilla，它用许多开发的资源系统来报告问题，相对而言，复杂工具的使用令变更处理自动化，包括从最初的客户提议到批准变更的整个过程。

办恶补你管理是跟踪软件组件或配置信息以及使用这些组件系统的不同版本的过程，版本管理也包括确保由不同开发者做出的变更不会彼此影响，因此，可以把版本管理过程看做是管理代码线和基线的过程。
本质上，代码线就是源代码版本的序列，一个晚期的版本是由某个早期版本发展而来。

代码线通常应用于组件一遍每个组件有不同的版本，基线是对一个特殊系统的定义。

可能会使用一种配置语言来详述基线，以便用户定义一个特殊系统版本所包括的组件。
基线很重要，因为开发者常常不得不重建一个完整系统的特定版本，
一个产品线需要实例化为不同客户产生不用的个人系统版本，假如客户报告了系统中错误，那么开发者不得不重建这个版本。

为了支持版本管理，应该经常使用版本管理工具，这些工具识别、存储并控制不同版本的存储，有许多可食用的版本管理系统，包括被广泛使用的开源系统，比如CVS和Subversion

版本管理系统通常提供一系列特征：
1版本和发布版本识别
2存储管理
3变更历史记录
4独立开发
5项目支持
当首次开发版本管理系统时，存储管理是其最重要的功能之一。版本控制系统中的存储管理特征减少了维护所有系统版本所需的硬盘空间，当创建一个新版本时，系统只创建新版本和较旧版本之间的不同之处的一个列表，然后根据这个列表来创建新版本。

大多数的 软件开发是一个软对活动，因此经常会有不同的团队在同一时间开发同一组件的情况，

为了使彼此之间不互相干涉，支持独立开发，版本管理系统使用一个公共仓库和一个私有工作空间的概念。开发者从公共仓库把组件取到他们的私有工作空间。并且可以在私有工作空间中按照他们的医院来变更组件。

相同组件独立开发的一个后果是可能会出现代码先分支。

在某一阶段，合并代码先分支以创建一个组件的新版本，使其包括所有一做的变更，这可能是必要的。
版本管理系统会通过对应用到代码的增量做混合使组件版本自动和恶病，更常见的情况是，所做变更会有重叠部分，它们会影响到彼此，开发者必须检查出冲突并且修改变更以使它们相兼容。

系统构建是把软件组件、外部的库、配置文件等编译和连接成一个完整的、可执行的程序过程，系统构建工具和版本管理工具必须进行通信，因为构建过程包括在版本管理系统管理的知识库中，检查组件版本信息。用于识别基线的配置描述信息也用于系统构建工具。

构建是一个复杂的过程，可能有三种不同的系统平台：
1开发系统，包括开发工具，比如编译器，源码编辑器等。

2构建服务器，用户构建确定的、可执行的系统版本。
3，目标环境，这是系统运行的平台。

开发系统和构建服务器都可以和版本管理系统进行交互。可以将虚拟机系统安装在构建服务器上或者一个专门的服务器上。对于嵌入式系统，可能在开发环境中安装一个模拟环境进行测试，而不是使用实际的嵌入式系统平台。

一个构建系统可能提供部分或者全部以下特征：

1构建脚本生成
2版本管理系统集成
3最小化再编译

4可执行系统创建
5测试自动化
6报告
7文档生成

构建脚本是一个对要构建的系统的定义，其中包含组件的信息以及它们之间的依赖关系，用于编译和连接系统的工具的版本信息。

由于编译是一个计算量密集的过程，支持系统构建的工具通常涉及使所需要的编译量最小化。
为了这目的，需要检测是否存在你可用的已编译版本，如果存在，就不需要重新编译这个组件。
签名能够识别各个源代码版本，当修改源代码后签名也改变，通过比较源代码和目标哦代码文件的签名，就能够决定是否使用源代码组件产生目标代码组件。

存在两类可以使用的签名
1修改的时间磋
2源代码校验和
由于目标代码文件没有正规的版本标识，第一种方法意味着只有最新编译的目标代码文件保存在系统中，目标文件一般通常通过名字和源代码文件联系起来。

校验和方法的有点是允许同时保留组件目标代码的多个不同版本。签名将源代码和目标代码联系起来。源代码和目标代码有相同的签名，因此，重新编译的时候，不会改写原来的目标代码，而时间挫的方式中会覆盖原来的代码，编译会生成新的目标代码文件，并贴上源代码的签名，并行编译是可以的，组件的不同版本可以同时进行编译。

敏捷方法建议：应该使用自动测试执行那些非常频繁的系统构建，从而发现软件问题。频繁构建可能是连续集成过程的一部分，为了配合敏捷方法的、进行小额改变的理念，持续集成过程的一部分，为了配合敏捷方法的、进行小的改变的理念，持续集成包括在对源代码做出小的改变后，频繁重构主线

持续集成的步骤主要是：
1将主线系统从版本管理系统中检出到开发人员的私有工作空间。
2构建系统并运行自动测试以确保所构建的系统能够通过所有测试，如果没能通过，构建终止，这时应该通知最后提交主线系统的开发人员。他们负责修复这个问题，
3完成系统组件的变更
4在私有工作空间构建系统并重新运行测试，如果测试失败，继续编辑。
5一旦系统通过测试，将它检入到构建系统，但是不要作为新系统基线提交
6在构建服务器上构建系统并运行测试，这样做事因为在检出系统后其他人有可能修改了组件，如果确实如此，检出失败的组件并进行编辑，使测试在私有工作空间通过。
7如果系统在构建系统上通过测试，将作出的变更作为系统主线中的一个新的系统基线。

持续集成的优点是，它允许尽快发现并且修复由不同开发人员的交互引起的问题，主线中最近的系统是确定的工作系统，然而，虽然持续集成是一个好想法，但在系统构建中实现这个方法并不总是可行的。
原因：
1如果系统很庞大，构建和测试可能要话费大量时间，因此不太可能每天构建系统几次。
2如果开发平台和目标平台爱不相同，就不大可能在开发人员的私有工作空间中运行系统测试，硬件、操作系统或者安装的软件都可能存在差异，因此需要更多的时间测试系统。
对于大型系统或者执行平台和开发平台不相同的系统来说，持续集成可能不太实际，在哪些环境下，可以使用每日构建系统，。
特征主要是：
1开发机构设定系统组件较丰富时间
2通过编译和连接这些组件构建系统的新版本，形成完整的系统。
3将系统交付给测试组，执行一系列预定的系统测试，同时，开发人员仍然继续编写组件，增加新功能，并修复之前测试发现的错误。

4记录系统测试中发现的问题，并交换给系统开发人员，他们随后的版本中修复这些问题。

使用软件频繁构建的好处是，找到一些问题的几率增加了，这些问题源于过程早期罪案的交互。

系统的发布版本是分发给客户的系统版本，对于大众市场软件，通常可能定义两种类型的发布，一种是主要发布，用于交付重要的新功能，另一种是小型发布，用于修复漏洞和修复用户报告的问题。

对于订制软件或者软件产品线，管理系统发布是很复杂的过程。
一个系统的发布版本生成事，必须编制文档来保证将来可以重新准确地复制它，这一点对定制的、生命周期长的嵌入式系统尤为重要。

为发布版本编制文档，必须记录用来产生可执行代码的源代码组件的特定版本。也要保存源代码文件、响应可执行代码以及所有的数据和配置文件。

准备并分发一个系统版本是个很高代价的过程，尤其是那些大众市场的软件产品。在准备发布版本的时候，处理必须准备的技术工作之外，还有广告、宣传材料以及到位的市场策略
系统的发布版本不仅仅是这个系统的可执行代码，发布版本还包括：
1配置文件，
2数据文件
3安装程序
4电子和书面文档，用于系统说明
5包装和相关的宣传，为发布版本所做的工作、

发布版本的创建是创建包含系统发布版本的所有组件在内的文件和文档集合的过程。
程序的可执行代码以及所有相关数据文件都必须在版本管理系统中找到，并贴上发布标识符。
对不同的硬件和操作系统要写出配置描述。
计划新系统发布版本安装的时候，发布版本管理者不能想当然地认为客户总是向安装新的版本系统。

由于发布软件产品的新版本会有很高的销售和包装成本，所以通常卖主们仅为新平台或在加入重要的新功能时才进行发布。

使用下载的布丁的问题是：许多客户可能永远发现不了这些问题布丁的存在，而且不能理解为什么需要安装。它们治好继续使用旧的有缺陷的版本，这是存在威胁他们业务的隐患。