什么是软件配置管理
“一套应用技术上和管理上的指导和监督的方法，用来：识别和记录配置项的功能特征和物理特征；控制这些特征的变更；记录和报告变更的处理和执行的状态；以及验证其是否符合特定的需求。”
基本的版本控制：记录版本，防止混乱
2.2 建立公共存储区
公共存储区是个星形结构
2.3 防止版本覆盖
第一种方法 串行的方法（锁定要修改的代码）
第二种方法 并行的方法
按任务单元组织工作
任务单元（Task）又称活动(Activity)。
从源代码的实际变动的角度看，任务单元对应于一个或多个文件上的一处或多处具体的代码改动。这些改动组合在一起，通常管它叫一个变更集
注意：每个任务单元所对应的工作量，不要太大。说对应的源代码改动，不要太多。否则，不好查阅修改情况，也不好管理。如果是个很大的任务单元，那就要考虑把它划分成若干小一些的任务单元
3.3 适时的更新工作空间
3.4 保证任务单元完成的质量
保证任务单元完成的质量，进而保证整个产品的整体质量，是每一个程序开发者的责任，绝不仅仅是测试工程师、集成工程师等角色的责任。
除了自测试外，有的团队还会引入同行评审（Peer Review）,又称为代码走查（Code Insepction）.
于此相关的是有些敏捷开发团队采用结对编程（Pair Programming）技术，目的之一也是提高程序质量
作为软件研发项目的协调者，管理者也需要做些事情，进到自己的职责，比如在产品即将上市，或进入维护期后，管理者要站出来，加强控制，加强评审，保证“让产品趋于稳定，并且尽快上市”这样的目标的实现
提交后，版本库里最新版本不能工作怎么办？？
常用办法：提交前，更新工作空间到当时产品的最新版本。然后，在工作空间里编译链接，并作粗略的测试，证明程序可以运行。这之后，在提交。
产品的整体版本
4.1 记录源代码的整体版本
整体版本，是项目开发的某一时刻的全部源代码的一个“截图”，行话叫“快照”（Snapshot）。
基线（Baseline）：被明显地标识和记录下来的源代码整体版本。
4.2 保存安装包
可以保存在共享目录下，该共享目录可在局域网上共享。
4.3 开发—测试—发布
在送交系统测试之前，除了保存源代码的整体版本，还应该保存安装包。
第五章关注源代码整体质量
集成的步骤
1、 应该确保开发人员都提交了相关的源代码
2、 冻结或者标识将要集成的源代码
3、 取出要集成的源代码，最好是存放到一个全新的工作空间
4、 编译，链接和打安装包。目的是由源代码生成可以测试、发布的安装包。这通常称为构建（build）。
5、 安装并粗略测试。仅仅能通过构建，通常是不够的。
6、 标识和储存集成成果。集成成果又两个，一个事源代码的整体版本，一个是生成的安装包。它们都要被合理的标识和存储
7、 通知相关人员，本次集成完成。
间接工作流(Non-immediateWorkflow)：更新到基线而非最新源代码上的方法。
直接工作流(ImmediateWorkflow)：总是更新到最新源代码上的方法。
每日构建(Daily Build/Nightly Build)：及早和经常的集成
持续集成(Continuous Integration)：持续集成认为，集成应该更为繁琐。
什么时候用到分层集成：内部高聚合，外部松耦合的时候需要。
第六章构件管理与环境设置
构建：简单的说，就是从源代码生产出安装包的过程。
从源代码到安装包这一生成转换过程，要有足够的管理，确保其可重复性。
1、 原材料是固定和明确的。
2、 工具是固定和明确的
3、 参数设置也必须是固定和明确的。这在具体执行编译、链接和打包的命令参数上体现出来
4、 生产过程是固定和明确的。
想要做到这一点，一个好的办法是自动化，尽可能的自动化。
全量构建与增量构建
全量构建：从头来过，从每一个源文件的编译开始
增量构建：尽可能地利用上次构建的成果。增量构建的输入，不仅包括原材料，还包括上次构件中，产生的中间产品，比如编译产生的很多中间文件。
记录构建相关信息：
1、 构建是怎么定的，怎么配的。
2、 构建的执行情况。
环境和设置：不止是在构建的时候
软件开发相关的环境：构建环境、开发环境、运行环境。
管理是发现、传播和共享的过程
第七章分支：减少等待，分头工作
文件级分支
产品级分支
典型应用一：实现多层集成
典型应用二：实现交迭
分支为什么这样有用：
1、 适当隔离
2、 适当共享
工作空间：本质是以产品的一个整体版本为起点，再加上一个未完成的任务单元。
工作空间支持隔离，支持共享
分支和工作空间都支持隔离和共享，为什么同时需要这两个：
两者各有优势和劣势，它们之间是相互配合、相互补充的关系，而不是相互替代的关系。
1、 分支无法代替工作空间。工作空间可以容纳未完成的任务单元，尚未检入和提交的修改，正在时时刻刻不断变化的修改，因此直接支持开发人员的日常工作。无论是否使用分支，一定要使用工作空间。
2、 只使用工作空间，不使用分支，常常是不够的。分支又3个优势：
A、可以同时容纳多个已提交的任务单元，并以此和其他分支相区别----工作空间只能容纳一个未完成的任务单元
B、分支存储在服务器上，比存储在本地的工作空间要安全
C、分支是所有人都能看见的，并且如果有必要，所有人都能在其上工作，而工作空间是单个开发人员自己的地盘，只有他可以在里面工作
分支有个弱点，就是不能改变其起始点。
第八章管理文档
文档的标识和存储
它们与源代码的不同主要体现在两方面：
1、 “文责自负”，因此，对文档的修改的协调，通常是用锁机制，或者干脆就不提供自动机制。
2、 “独立成篇
自带的说明信息
文档常有明确的所有者，由他修改，其他人只是阅读。文档通常独立成篇，文档间的耦合性不强。因此文档的传递和复制，通常管制比较松。这就要求，文档本身的一些信息，比如版本信息等，要由它自身携带。
文档中起始的一到二页，常常用来更全面地记录和展现相关信息：
1、 关于文档的名称，在文件名中，可能只是以缩写体现的。在文档中就应该给出文档名称的全名。
2、 应该以某种方式，指出文档的“出处”。
文档通常会有一定的密级，不同的文档，密级可能不同。应该在文档起始页明确标出文档的密级，让使用者留意自己的行为。这是公司司法务部门特别关注的，他们同样关注版权信息。这通常也明确标识在文档的起始处。
对于当前版本的信息，主要有三项：1、版本号 2、版本产生时间 3、版本目的或状态 对于文档也类似
文档的状态，通常有如下三种：1、草稿(Draft) 2、评审中(InReview) 3、已发布(Released)
文档的作者和参与者的信息，也应该被记录。比较全面的的记录内容包括：
l
谁是这份文档的主人，对文档的内容及文档书写的协调工作责任？
l
哪些人是这份文档的主要作者，书写了这份文档的绝大部分内容？对于中小型文档，通常主要作者只有一个人，且他就是文档的主人。
l
哪些人为这份文档做出了贡献，包括正式的评审和非正式的建议等？
l
如果这份文档是已经被批准，正式发布的文档，那么，是那些人批准的，以谁的名义发布的?
关于版本历史信息。每次修改并保存版本，通常要记录如下信息：
l
修改后的版本号
l
修改完成的时间
l
本次修改的修改者
l
这个版本的最终状态
l
对修改的简单描述
趋势：WIKI
如果想知道关注的特定内容在哪个文档里，就得依次打开各个文档，看其简要介绍。为了去除这些不便之处WIKI产生
WIKI首先是一种语言，一种像HTML一样的既有内容，又有格式的语言。
登陆WIKI系统，在特定页面的可编辑区域里，用WIKI语言书写，修改和保存。而在展现给别人的时候，WIKI系统会自动把它翻译成了HTML语言，在浏览器中显示。
WIKI定位与“面向社群的协作式协作”。它很好的做到了这一点。
趋势：数据文件和数据库
更好的方法是用一套需求管理工具来管理需求信息。每个需求是一个条目，条目可以有各种属性；条目有它的修改历史；条目之间的关系被记录，一旦一个条目被修改，相关的条目会被提醒要不要修改，等等。需求管理工具把这些数据，保存在特定各式的数据库文件里，或者数据库里。使用需求管理工具来记录和管理需求，比用一般文档文件来记录和管理需求，要方便地多
还有些工具，为软件开发活动提供支持。这里，讨论关于这些工具所保存和使用的数据的管理工作。这些数据，同样是软件项目的资产，同样应该进行软件配置管理。这主要通过两种途径实现：
由相关工具本身提供一定的软件配置管理功能。
对数据文件或数据库，进行外在的、整体的管理。
途径一和途径二相辅相成。
第九章
跟踪缺陷，直到消灭
Bug跟踪系统，学名叫缺陷跟踪系统（Defect Tracking System.）
发现了这个缺陷，并且报上来。（Reported已报告）
大致看看这个缺陷，并分配给合适的程序员去处理。(Assigned已分配)
解决这个缺陷，这道工序由程序员来完成。（Resolved已解决）
确定这个缺陷真的被修复了(Closed已关闭)
准确记录，便于修复
每条缺陷记录，有一行标题（Title）,或者叫总结(Summary),简述缺陷的内容。
还有一些字段能起到类似作用，比如关键字（Key Words）。
对于真正修改源代码以修复缺陷的程序员而言，它们需要对缺陷的详细描述，这通常通过让缺陷报告者填写细节描述(Description)区域来实现
对缺陷的详细描述，一定要做到可以复现这个缺陷。要详细记录当时的操作环境，当时的操作步骤，以及当时的缺陷现象。 对缺陷的详细描述，是处理缺陷和检验处理结果的依据，十分重要！
在有些缺陷跟踪跟踪系统里，除了可以用文字详细描述缺陷外，还可以上传相关附件，比如，当时缺陷情况的截图或使得程序保存的输入数据文件等。
救护是依据伤员布条的颜色，修复缺陷也有类似的属性。它们是两个：严重程度和优先级
我们需要遵循一个原则，那就是，避免带着许多缺陷前进，缺陷应该尽快被消灭。
关联缺陷记录与任务单元
缺陷记录与任务单元之间的关系，并不一定总是一对一的关系。有的缺陷的修复，需要对程序有比较大的调整，需要多个人一起配合，于是，需要有多个任务单元。而另一些时候，几个相关的缺陷，可能是通过一个任务单元就都修复了
分析统计缺陷相关数据
在缺陷管理方面，我们有典型的三类统计。这三类统计，各有益处：
用来回答缺陷是怎么分布、数量是多少。
用来回答随着时间的迁移，缺陷的总体趋势是什么样的。
关于缺陷年龄的统计。
另一种展现方式，是报表：报表的好处是，文字上的东西可以多些；具体的数字，可以看的更清楚些；交给领导，也更像样子。
第十章管理变更
比缺陷更广阔的话题，是变更请求，比变更请求更广阔的话题，是变更。
变更在不同的文档中，在不同的上下文中，有不同的含义，而我们更关心的是功能需求上的变更请求，架构设计上的变更请求。
管理细小的变更
功能增强（Enhancement）：指一些小小的请求，请求吧程序已有的功能，稍稍增强一点，或者稍稍改变一下。
对这类请求的管理，就有点像缺陷的管理：缺陷的特点1、数量多，容易丢；2、通常每个涉及的改动工作量都不大，经常是一个任务单元就能完成；3、通常每个缺陷都能明确对应到源代码的改动；4、通常缺陷之间相互独立，不要通盘考虑。 正是因为这样的特点，所以把缺陷按条目记录，进而分别跟踪、处理，直至解决。
但是功能增强的处理流程，与缺陷的处理流程，也有所不同。这主要体现在两点上：
需要对功能增强有仔细的评估，进而确定是否要实现。
功能增强所导致的修改，常常不仅是源代码的修改。
在瀑布模型中管理变更
瀑布模型希望能够借助在传统工程中的成功经验，来实现软件开发项目的成功。
瀑布模型希望也能用这样的方法进行软件开发。
在瀑布模型中，变更的管理很重要。其主要的关注点是：一但定下来的事，就要执行，不能乱改。要减少变更，变更不能随意发生。所以，变更管理的核心是，严格控制变更。
一个常见的做法，设立变更控制委员会（Change Control Board,CCB）
在迭代模型中管理变更
它的思想核心是，尽早反馈。
迭代式开发把一个大项目在时间轴分解成很多个小项目，每个小项目被称作一个迭代（Iteration）。几乎每次迭代都会包含需求分析，系统设计，代码实现，以及集成和测试。
在每次迭代的过程中，通常不会接受新的变更，特别是比较大的变更。每次迭代的时间不长，一般只是三四个星期，应该集中精力在要做的事情上，而不是对要做什么犹豫不决。
影响变更控制的因素
作为严格的变更控制，需要在变更提出时，填写足够详尽的相关信息。然后是足够的变更评估，评估变更影响的方方面面。之后，做出变更决定。这也要经过充分讨论，并最终取得一致。接着，是变更的实施，对源代码和文档的改动。变更实施后，要经过足够的测试和验证，保证变更真的发生了，真的正确地发生了。
不是所有的变更，都要经历这么严格的控制,那么，哪些因素会影响对变更的控制程度和控制流程呢？
l
变更的类型
l
变更的大小
l
变更的影响面
l
变更的风险
l
变更发生的时间
l
研发规模
记录产品版本间的差异
发布给用户的文档，除了关于整个产品的描述文档，比如使用手册外，还要有关于版本间差异的说明。这通常在发布说明（Release Notes）文档中实现。
现在，我们重点关注版本间差异的说明。我们如何产生这个说明？信息从哪儿来？
有四个途径：
查看版本控制系统。
查看变更请求数据库
查看项目计划或迭代计划
查看需求数据库或需求文档
控制产品版本间的差异
在版本控制系统里，我们可以加一些控制，以保证程序员做且只做该做的事：
第一种方法是，让任务单元不是由程序员创建，而是由管理人员创建，然后指定给相应的程序员完成。
第二种方法是事后控制。在程序员完成了任务单元后，如果想提交，需要得到某种批准。只有符合本次版本需要的任务单元，才可以提交。
第十一章产品整个生命周期内的配置管理
制定计划
计划文档的内容及详略在不同的项目间有极大的差异。计划文档内容及繁简，主要受以下几方面因素的影响：
组织级软件配置管理系统建设的情况，包括工具
特定项目“与众不同”的程度。越是特殊的项目，越需要更多的计划，并体现为计划文档的内容。
特定项目的软件配置管理的复杂性。
软件配置管理计划中的内容，可能会随着时间的推移、项目的进展而改变。应该积极面对这样的变化，适当调整计划，并反映在计划文档上。文档需要持续维护。
做好准备
软件配置管理系统，可大致分为工具、过程和人三个方面。要做好软件配置管理系统的运行准备，就要做好这三个方面的准备
监控、调整与改进
软件配置管理系统的运行，既需要参与者的深刻理解和自觉执行，也需要某种形式的监控。
第一类调整：项目的软件配置管理策略、方法，需要随着项目的紧张进行调整。
第二类调整：在制定计划时，不能准备地估计到项目对软件配置管理的需求；不能准确地估计到在这个项目中，各项软件配置管理工作应该怎么做，应该做到什么程度。
随着对软件配置管理的认识不断提高，会对流程进行调整；随着新的软件配置管理工具的选型、购买、安装设置的完成，会对项目所用工具进行调整。这类以提
升为主要特征的调整，通常被称为改进。
收尾
在产品发布、项目收尾阶段，软件配置管理同样需要进行收尾工作。这主要包括两个方面，软件资产的整理和归档工作、软件配置管理本身的总结和共享工作。
第十二章玄妙的学院派
配置管理由配置识别、配置控制、配置状态报告、配置审计四部分组成。
配置识别（Configuration Identification）
包括选择产品的配置项、为它们指定唯一的标识，并在技术文档中记录其功能和物理的特征。
配置控制 (Configuration Control)
包含评估、协调、批准/拒绝、实施对配置项的变更。这应该发生在正式的配置识别之后
对于变更，还有协调的工作要做，这主要体现在三个方面：
在不同的变更请求之间的关联性。
一个变更请求，可能会影响到不同的产品，因为它所进行的改动，是在一个公共组件上，这个组件被好几个产品使用。
体现在完成的先后顺序上，有的请求比较紧急，有的请求比较重大，要优先安排人力资源去完成，有些则可以拖一拖。
配置状态报告 (Configuration Status Report)
记录和报告用来有效管理配置所需的必要信息。这些信息包括一个已批准的配置识别清单，变更请求当前的处理状态，以及已批准的变更的实现情况。
配置审计 (Configuration Audit)
执行审计以验证配置项符合特定的标准或需求
配置审计定义中所说的审计，是指对象本身是否符合需求和相关的标准，而不是制作对象的过程。
那么软件配置项的审计，是指什么呢？
首先，是要确保需求文档反映了客户的需求，设计文档反映了需求文档的要求，源代码实现了设计文档的目标。这样一层层递进，以确保跑起来的程序，就是客户想要的。
其次，在源代码写完之后，要进行单元测试；集成时，要做粗略测试；进而，由系统测试团队进行系统测试；最后，由用户或用户代表进行接受测试。
审计又被分为功能审计和物理审计
在相关标准里
在能力成熟度集成模型（Capability Maturity Model
Integration,CMMI）中，对包括软件配置管理在内的配置管理工作，从如下角度进行了划分。
l
建立基线
首先，识别配置项；接着，建立配置管理系统，用来存放配置项；最后，通过评审或测试后，由配置项组成基线，作为未来开发的基础。
l
建立并控制变更
l
建立完整性
首先，要对配置管理活动做足够的记录；其次，要进行配置审计。
以上3个方面，是针对配置管理的要求。还有两方面，使用于各方面的管理，配置管理也需要：
l
制度化已管理过程
在一个软件研发项目中做配置管理，首先要建立配置管理计划，然后确保有足够的资源，包括工具、环境、也包括人员。在配置管理系统运转过程中，要适当监控。
l
制度化已定义过程
要形成可以指导现在和未来多个软件研发项目的配置管理过程规范。这样的规范不是一成不变的。要收集相关的信息、数据和反馈，并基于此，进行软件配置管理的持续的改进。
在软件能力成熟度模型（Capability
Maturity Model for Software,SW-CMM）
l
执行约定
l
执行能力
l
执行的活动
l
度量和分析
l
验证实施
-- 
学海无涯