我工作在变更与版本管理（C&RM）领域已经有一段时间了，我看到过数以百计的公司在处理创建、发布和跟踪复杂软件项目的挑战时所采取的应对方式。随着时间的积累，在这个领域中陆续出现了一些清晰的模式。遵循这些模式，软件开发处理过程的质量就能够得以保障。在本文中，我们基于一家大型的电子学和半导体测试公司的例子（以下简称为“该公司”）——该公司是 Rational 产品线的一位长期客户——探索该公司所面临的挑战，然后我们给出七种实践方案来帮助该公司解决这些和软件企业的成功密切相关的问题。
面临的问题
为了更好的理解该公司当前的状况，在公司内部进行了一次评估行动，以获得关键的利益攸关者（即版本工程组的内部客户）的反馈信息。这次评估所暴露的一些主要问题，正是我在这个行业中所反复看到的。所以我相信，读者在阅读这篇文章的时候，一定会感觉到有许多情况似曾相识。
然而，最有意思的发现是：与其他许多公司不同，这家公司尚没有意识到挑战、构建和发布过程并不是存在于真空之中的。频繁作为“构建问题”或者“展开问题”出现的典型问题，都能够被追溯到诸如需求收集、编码实践、测试方法、甚至是产品体系结构设计等基础问题。在产品开发周期的这些阶段上所做出的不完全的思考和决定，常常在产品的发布和维护阶段突然出现。
我将问题归纳为如下这些方面：
构建时期
这些问题毫无例外都是构建的整体性和对系统组件之间的相互关系的不适当理解所导致的结果。从某种意义上说，处理能力或者明确的构建策略能够减少所需要的时间，但是却不能对这个问题产生任何重大的影响。
过多的构建线路或者不足够自动化的测试
正如前面所提到的，这个分组需要在适当的位置处理当前的分支策略。对于一个仅有百余个开发人员的公司来说，同时拥有 100 个活动的开发流实在是太多了。过多的工作是由集中的构建团队来完成的，并且它们并没有充分地被一个强大的企业级构建管理工具自动执行。即使它们在一个构建上运行 1000 个单元测试，并且每天完成 30 个这样的构建，但是这依然是不够的。在当前的状况中，有太多的手工努力来支持团队，有太多的硬件没有被有效地利用。通常来说，这种分支策略需要被进一步的研究。具有讽刺意味的是，尽管这里有“太多的”构建线路，但是却没有一个充分的构建。活动分支的数量，导致稳定曲线在诸如综合和重建基础等拐点上的巨大的挥发性。研究显示：许多小型的综合较之那些大型的综合，对于一个项目的成功具有明显较好的作用。如果有一个更加有效的分支策略的话（再加上下面两个抑制因素的解决方案），更多的构建将在现在的基础上以更小的工作量和更少的时间被执行。
缺乏一致的、全面的、综合的变更管理处理过程
就问题类别而言，缺乏一个全面的、自动的变更管理处理过程严重影响着该公司里的许多工作组。例如那些为了满足 Change Control Board 的需求而完成的手工任务，都应当被自动化地完成。代码回顾应当作为变更管理处理过程之中的一个强迫的和完整的部分。回溯到初始需求从而确保所有的需求都被执行和测试，这在任何一支管理良好、运作高效的软件开发团队中都处于核心地位。如果没有这样的追溯的话，测试就无法进行，状态就无法获得（或者手工的报告），额外的工作需要被完成，项目的全面状态的可靠的可见性将大打折扣。如果没有一个可靠的、基于事实的项目状态图景的话，有效的项目管理和变更响应将是天方夜谭。
不同公司之间对于如何实施变更管理的差异性，导致了混乱和效率低下，并且通常还会限制大型公司的灵活性和洞察力。这还将导致诸如不确定将初始源代码放到客户问题系统中的哪个位置等情况。进一步地，该公司内部的各个工作组之间缺乏对彼此所做工作的理解。即使是直接使用对方工作产品的工作组也缺乏对对方工作组的可见性。在采访期间，我们经常听到这样的抱怨“我真不知道您做了什么。”如果我们将一个集中的、通用的和一致的变更管理方案放在一个工具中执行，那么将会消除这种混乱。
不佳的组件和完全无法书面证明的依赖
缺乏一致的变更管理处理过程的另一个方面，在评估期间所发现的大部分问题都能够被追溯到（至少是部分上）缺乏一个清晰的和被文件证明的组件模型。缺乏对构建顺序的理解、缺乏对代码模块的提供者和消费者之间的合同的定义和强制、以及构建所具有的完全的整体性，正是以下诸多问题发生的根源：无法重新启动构建过程、无法完成部分可靠的构建、无法进行有效地测试、无法对变更（补丁和升级）进行影响分析，等等。根据通常的构建速度，硬件和策略（例如：ClearMake 所具有的进行构建避免的能力）能够使我们超越当前所处的阶段，但是最终唯一的解决方案只能是：对代码的根本体系结构进行分解和建模，并且真正理解各个部分是如何在一起工作的。
构建过程的脆弱性
开发人员在整体开发流中的当前状态下无法进行“起飞前的准备工作”，其原因主要有两个方面。一方面是构建时间，我们已经在前文中加以分析。另一方面进行构建可靠性所需要的环境没有得到很好的指定。造成这一现象，部分原因在于缺乏对根本的系统对象的依赖关系的理解（例如操纵系统依赖关系和 Visual Studio 版本），部分原因在于基于组件对象模型（COM）开发的根本特性及其对 Windows 的依靠。一个支持商业构建管理解决方案的构建处理过程将是十分有用的。一个自动配置和安装测试环境的工具甚至会更有帮助。这种对于特定的基础开发平台的无正式文件记录的依赖关系，还将影响到此后所进行的复制构建的能力。
测试处理过程的脆弱性
测试处理过程虽然是相当全面的，但是开发人员和构建公司还是会受到某些非常特定的问题的影响。正如上面所提到的，在整个开发周期中都普遍缺乏可追溯性，并且这一缺乏扩展到了测试领域之中。没有一种方法可供用来追踪处理过程和需求覆盖。开发团队无法在一个构建之后得到一份简明显示工作和失败测试的报告，也无法对特定区域代码的测试执行进行跟踪。覆盖工具对于测量代码级别的代码覆盖来说并没有任何用处，代码质量工具对于自动检测内存泄露和执行问题来说也没有任何用处。
关于测试的变更管理处理过程是手工的和记录不良的。在没有一个商业的测试管理知识库的情况下，测试人员所依靠的就是当影响测试的代码发生变更时以电子邮件的形式加以通告。一个保存测试执行信息的访问数据库的使用，意味着对于个体的测试案例或者测试计划没有单元级别的变更控制。举例来说，我们的采访揭开了当前处理过程中的一个重大的失误，它导致了自动化的测试运行在测试数据库的非基线的版本上。这将给开发人员带来虽然是偶尔的，但却是严重的困难，它将迫使他们追赶虚幻的测试失败。除此之外，测试的分支建模将导致由于完成不同功能的测试具有相似的名称所带来的混乱。
最后，上述和变更管理和组件相关的缺点，意味着没有一种方法能够进行变更级别的影响分析。解决这些问题将极大地加快我们的测试处理过程，确保那些宝贵的资源被用在最能发挥其作用的地方。（这并不是说一定量的衰退测试是不重要的，是的，它的确很重要，但并不是对于每一个增量构建都重要。）
展开十分混乱
展开处理过程划分为若干个类别。本地的机器展开是需要开发人员完全手工完成的 —— 开发人员必须手工地升级他们的注册，将文件复制到构建代码，然后在本地运行产品进行测试。这依赖于软件“套件”的产品，即复制为二进制的形式，并且手工地（通过脚本）安装到开发人员的工作站上。更新处理过程也是手工的，并且有规律地发布新的套件。然而，当套件由于构建问题被延期的时候，开发人员就无法访问从其他人那里得到的对象，这就迫使他们必须等待那些构建被完成并且新的套件被展开之后才能继续进行他们自己的工作。数亿十亿字节的套件的全球展开是一件十分麻烦并且需要大量资源的事情。人们正在试图降低这一操作的复杂度，但是仍然存在同构建时间相关的瓶颈。
将产品展开到客户可交付的盒子上对于开发团队来说是一件十分神秘的事情。尽管这是一个与代码的展开高度相关的案例，就像用于公司的变更处理过程的监护人一样，但是变更和发布工程学开发团队还是应当非常注意在他们生成的代码上所发生的每一件事情。否则，当交付时出现问题的时候，他们就无法验证或者复制那些他们交付给客户的结果。
成功的变更管理团队的特征
正如前面所讨论的那样，一家版本工程学公司的首要职责就是管理变更的流程。所有被版本工程学所支持的工具和处理过程都是和授权变更、跟踪变更、构建变更、并且最终将变更交付给内部或者外部的用户相连接的。最后，我们根据在构建和发布中的需要，从更广阔的方面对最初的讨论进行了重新组织。在完成这些操作之后，我们总结出以下这些成功的公司所共同具备的特点。
