现在大家都已经熟悉到了有效的软件配置治理工作对于提高团队开发效率、保障软件产品质量的重要意义，很多朋友也开始了在配置治理实施方面的一些研究，市场上我们也可以看到一些软件配置治理工具厂商针对具体配置治理工具提供的实施服务；但是，实施软件配置治理到底应该做哪些东西？团队的配置治理现状怎么评估？在哪些方面还可以进行改进？我们相信，这些问题可能正困扰着大多数研发主管和项目经理。国外软件产业界在软件配置治理这个专题上已经进行了多年的理论和实践上的研究。在多年经验积累的基础上，产业界总结出来一系列“最佳实践”（Best Practices），我们可以使用这些“最佳实践”来作为评估一个组织软件配置治理能力的标尺，也可以作为我们实施软件配置治理的指南。这些“最佳实践”包括：
1、标识需要进行存储的工件（Artifact）并保障安全存储；
2、控制并且审计（Audit）对于工件的修改；
3、设立并治理基线（Baseline）；
4、记录并跟踪变更请求；
5、维护稳定、一致的工作空间；
6、支持对于工件和控件的并发修改；
7、尽早集成、持续集成；
8、保证软件构建的重现能力；
9、以控件（Component）为单位实施版本控制；
10、使用“活动”（Activity）来组织和整合版本集。
下文将介绍前5条最佳实践。
1、标识需要进行存储的工件（Artifact）并保障安全存储
在软件开发过程中，我们会得到各种各样的产出，比如各种文档、模型、源代码以及测试脚本等，我们把这些大家劳动的成果统称为工件（Artifact）。对于一个软件开发组织来说，这些工件就构成了组织的核心资产。对于如现金、有价证券之类的资产，我们都会预备一个保险箱，好好地保存；对于软件资产，我们也需要相似的措施。所以，软件配置治理工作的第一步就是建立一个安全、可靠的存储库（Repository），用于保存组织的核心软件资产。
这个库对于开发团队来说，就像是财务室里的保险箱。因此，容错能力和高可靠性是这个库最重要的属性。除此之外，随着组织的增长，置于库中的数据会越来越多，为保证运行效率，库的可扩展性也是非常重要的一个属性。
对于存储库来说，良好规划的备份和灾难恢复过程是必不可少的。令人惊奇的是，很多软件组织在这方面都没有给予必要的重视，因而也给组织的发展留下了严重的隐患，一旦灾难发生，后果不堪设想。
在建立好存储库以后，需要做的工作就是确定将哪些工件置于库中。根据实际需要，组织可能会决定只将正式文档、模型文件、源代码、发布版本等文件放入库中，而对于临时文档、编译时产生的中间文件等，则不将它们放入库中。我们把放入库中的文件称之为配置项（Configuration Item）。
2、控制并且审计（Audit）对于工件的修改
在标识相关的工件并将它们置于存储库中以后，我们需要建立对于这些工件的修改控制机制以及审计机制。
库里的工件不是谁想修改就可以修改的。控制机制必须保证只有拿到授权的人员才能对相关工件进行修改，而审计机制则保证修改的动作被完整地记录，也就是说，谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方（Who、When、Why、What）。
审计机制通常通过“检出/检入”（Check out/Check in）模式得到实现。在这种模式下，工件一旦入库，读写权限就变成只读（read only），假如要对该工件进行修改，则需要通过“检出”这个步骤；在修改结束以后，假如希望将修改的成果入库，则需要通过“检入”这个步骤。在经过一次“检出/检入”步骤以后，会形成该工件新的版本，因此也有人把上边的过程称之为“版本控制”（Version Control）。在版本控制过程中，假如利用一些配置治理工具（或者版本控制工具）的支持，则可以自动地记录审计工作所需的四个“W”（Who、When、Why、What）。
3、设立并治理基线
通过审计机制我们可以保存一个工件完整的变更历史；但是一个项目通常是由成百上千个工件构成的，每个工件在变更过程中都会形成一系列的版本，如何确认系统在某个时刻分别由哪些工件的哪些版本构成？这就需要引入一个概念：配置（Configuration）。对于软件系统来说，在开发过程中某个时刻存储库中所有工件的一个“快照”（snapshot），就形成一个“配置”。对于一些重要时刻的系统配置，我们可以使用基线（Baseline）来进行标志。
IEEE对于基线的定义是：已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变.简单地说，基线就是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于这个标准进行，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对它进行的变更都将记录为一个差值，直到建成下一个基线。
建立基线的主要原因是：重现能力、可追踪性和报告能力。
重现能力是指返回并重新生成软件系统给定发布版本的能力。可追踪性建立项目各种类型工件（需求、设计、实现、测试等）之间的横行依靠关系，其目的在于确保设计满足需求、代码实施设计以及使用正确代码编译生成可执行文件。报告能力来源于一个基线内容同另一个基线内容的比较，基线比较有助于程序调试并生成发布说明（Release notes）。
建立基线有以下几个好处：
(1) 基线为开发工件提供了一个定点和快照。新项目可以从基线提供的定点之中建立。
(2) 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
(3) 可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现被报告的错误。
在开发过程中，需要定期建立基线以确保团队开发人员的工作保持同步，通常，在项目生命周期中的里程碑处定期建立基线。
4、记录并跟踪变更请求
以上我们谈论的都是对于工件的变更活动的实施，下面我们要谈到的是软件配置治理的另一个方面：对于变更请求的治理。这是变更活动的源头。
闻名的软件大师Brooks曾经谈到导致软件开发困难的一个原因就是软件的可变性。大家都知道，各种要素，如市场的变化、技术的进步、客户对于项目熟悉的深入等等，都可能导致软件开发过程中的变更请求的提出，而且承认这种变更请求的合理性也已经是工业界的共识。
但是，假如缺乏对于变更请求的有效的治理能力，纷至沓来的变更就会成为开发团队的噩梦。缺乏有效的变更请求治理会导致以下一些问题：
（1） 软件产品质量低下，对一些缺陷的修正被遗漏；
（2） 项目经理不了解开发人员的工作进展，缺乏对项目现状进行客观评估的能力；
（3） 开发人员不了解手头工作的优先级别，可能出现将紧急的事情放在一边、而工作在一般优先级任务上的情况。
变更请求治理的复杂程度与变更的具体类型有关。简单地说，变更请求治理会涉及到变更请求的提交、变更请求的复审、变更任务分配、变更结果的验证等一系列活动。通常，变更请求治理的流程是：由请求者提交变更请求，变更控制委员会（Change Control Board，CCB）召开CCB复审会议对变更请求进行复审，以确定该请求是否为有效请求。假如是，则基于项目团队所确定的优先级、时间表、资源、变更难度、风险、严重性以及其他相关标准，判定对该变更的修改程序，并分配实施变更任务的人力资源和时间资源；变更任务实施人员负责实施该变更；实施结束以后提交验证人员，由验证人员负责对变更结果进行验证，假如变更成功则通知相关人员，否则由变更实施人员返工。
典型的变更请求治理如需求变更治理、缺陷追踪等。实施有效的变更请求治理有以下好处：
（1） 提高软件产品质量；
（2） 提高开发团队沟通效率；
（3） 帮助项目治理人员对产品状态进行客观的评估。
关于变更请求治理的具体过程以及相关准则PMT将在相关报告中阐述。
5、维护稳定、一致的工作空间
在我们把相关工件纳入集中的存储库、大家也都遵照“检出/检入”的工作模式对工件进行修改以后，下一步的工作就是要为每位开发人员设定“私有”的工作区，或者叫做工作空间。 工作空间通常以特定的基线为基础创建，要求能够做到为指定的任务方便地取出正确的工作版本建立私有工作空间；开发人员根据项目要求在自己的私有空间中对工件进行修改和测试活动，而与其他开发人员相对保持隔离，也就是说，自己的修改活动不会受到他人的影响，也不会影响到其他开发人员。但是，在保持隔离的同时，又应该提供相应的机制，当开发人员希望共享工作成果的时候，能够很方便地实现共享。
开发人员日常的开发工作都是在工作空间里进行的，因此，稳定性应该是工作空间首要的特性，只有高度稳定的工作空间才能保证开发人员的工作效率。
