这是一个非常详细的案例研究，它描述了一家电子学和半导体测试公司在构建和发布方面所面临的挑战，并且描述了这家公司发展成为一家“世界级的”变更和版本管理公司所采取的步骤。
我工作在变更与版本管理（C&RM）领域已经有一段时间了，我看到过数以百计的公司在处理创建、发布和跟踪复杂软件项目的挑战时所采取的应对方式。随着时间的积累，在这个领域中陆续出现了一些清晰的模式。遵循这些模式，软件开发处理过程的质量就能够得以保障。在本文中，我们基于一家大型的电子学和半导体测试公司的例子（以下简称为“该公司”）——该公司是
Rational 产品线的一位长期客户——探索该公司所面临的挑战，然后我们给出七种实践方案来帮助该公司解决这些和软件企业的成功密切相关的问题。
为了更好的理解该公司当前的状况，在公司内部进行了一次评估行动，以获得关键的利益攸关者（即版本工程组的内部客户）的反馈信息。这次评估所暴露的一些主要问题，正是我在这个行业中所反复看到的。所以我相信，读者在阅读这篇文章的时候，一定会感觉到有许多情况似曾相识。
然而，最有意思的发现是：与其他许多公司不同，这家公司尚没有意识到挑战、构建和发布过程并不是存在于真空之中的。频繁作为“构建问题”或者“展开问题”出现的典型问题，都能够被追溯到诸如需求收集、编码实践、测试方法、甚至是产品体系结构设计等基础问题。在产品开发周期的这些阶段上所做出的不完全的思考和决定，常常在产品的发布和维护阶段突然出现。
我将问题归纳为如下这些方面：
构建时期
这些问题毫无例外都是构建的整体性和对系统组件之间的相互关系的不适当理解所导致的结果。从某种意义上说，处理能力或者明确的构建策略能够减少所需要的时间，但是却不能对这个问题产生任何重大的影响。
过多的构建线路或者不足够自动化的测试
正如前面所提到的，这个分组需要在适当的位置处理当前的分支策略。对于一个仅有百余个开发人员的公司来说，同时拥有
100 个活动的开发流实在是太多了。过多的工作是由集中的构建团队来完成的，并且它们并没有充分地被一个强大的企业级构建管理工具自动执行。即使它们在一个构建上运行
1000 个单元测试，并且每天完成 30 个这样的构建，但是这依然是不够的。在当前的状况中，有太多的手工努力来支持团队，有太多的硬件没有被有效地利用。通常来说，这种分支策略需要被进一步的研究。具有讽刺意味的是，尽管这里有“太多的”构建线路，但是却没有一个充分的构建。活动分支的数量，导致稳定曲线在诸如综合和重建基础等拐点上的巨大的挥发性。研究显示：许多小型的综合较之那些大型的综合，对于一个项目的成功具有明显较好的作用。如果有一个更加有效的分支策略的话（再加上下面两个抑制因素的解决方案），更多的构建将在现在的基础上以更小的工作量和更少的时间被执行。
缺乏一致的、全面的、综合的变更管理处理过程
就问题类别而言，缺乏一个全面的、自动的变更管理处理过程严重影响着该公司里的许多工作组。例如那些为了满足
Change Control Board 的需求而完成的手工任务，都应当被自动化地完成。代码回顾应当作为变更管理处理过程之中的一个强迫的和完整的部分。回溯到初始需求从而确保所有的需求都被执行和测试，这在任何一支管理良好、运作高效的软件开发团队中都处于核心地位。如果没有这样的追溯的话，测试就无法进行，状态就无法获得（或者手工的报告），额外的工作需要被完成，项目的全面状态的可靠的可见性将大打折扣。如果没有一个可靠的、基于事实的项目状态图景的话，有效的项目管理和变更响应将是天方夜谭。
不同公司之间对于如何实施变更管理的差异性，导致了混乱和效率低下，并且通常还会限制大型公司的灵活性和洞察力。这还将导致诸如不确定将初始源代码放到客户问题系统中的哪个位置等情况。进一步地，该公司内部的各个工作组之间缺乏对彼此所做工作的理解。即使是直接使用对方工作产品的工作组也缺乏对对方工作组的可见性。在采访期间，我们经常听到这样的抱怨“我真不知道您做了什么。”如果我们将一个集中的、通用的和一致的变更管理方案放在一个工具中执行，那么将会消除这种混乱。
不佳的组件和完全无法书面证明的依赖
缺乏一致的变更管理处理过程的另一个方面，在评估期间所发现的大部分问题都能够被追溯到（至少是部分上）缺乏一个清晰的和被文件证明的组件模型。缺乏对构建顺序的理解、缺乏对代码模块的提供者和消费者之间的合同的定义和强制、以及构建所具有的完全的整体性，正是以下诸多问题发生的根源：无法重新启动构建过程、无法完成部分可靠的构建、无法进行有效地测试、无法对变更（补丁和升级）进行影响分析，等等。根据通常的构建速度，硬件和策略（例如：ClearMake
所具有的进行构建避免的能力）能够使我们超越当前所处的阶段，但是最终唯一的解决方案只能是：对代码的根本体系结构进行分解和建模，并且真正理解各个部分是如何在一起工作的。
构建过程的脆弱性
开发人员在整体开发流中的当前状态下无法进行“起飞前的准备工作”，其原因主要有两个方面。一方面是构建时间，我们已经在前文中加以分析。另一方面进行构建可靠性所需要的环境没有得到很好的指定。造成这一现象，部分原因在于缺乏对根本的系统对象的依赖关系的理解（例如操纵系统依赖关系和
Visual Studio 版本），部分原因在于基于组件对象模型（COM）开发的根本特性及其对 Windows
的依靠。一个支持商业构建管理解决方案的构建处理过程将是十分有用的。一个自动配置和安装测试环境的工具甚至会更有帮助。这种对于特定的基础开发平台的无正式文件记录的依赖关系，还将影响到此后所进行的复制构建的能力。
测试处理过程的脆弱性
测试处理过程虽然是相当全面的，但是开发人员和构建公司还是会受到某些非常特定的问题的影响。正如上面所提到的，在整个开发周期中都普遍缺乏可追溯性，并且这一缺乏扩展到了测试领域之中。没有一种方法可供用来追踪处理过程和需求覆盖。开发团队无法在一个构建之后得到一份简明显示工作和失败测试的报告，也无法对特定区域代码的测试执行进行跟踪。覆盖工具对于测量代码级别的代码覆盖来说并没有任何用处，代码质量工具对于自动检测内存泄露和执行问题来说也没有任何用处。
关于测试的变更管理处理过程是手工的和记录不良的。在没有一个商业的测试管理知识库的情况下，测试人员所依靠的就是当影响测试的代码发生变更时以电子邮件的形式加以通告。一个保存测试执行信息的访问数据库的使用，意味着对于个体的测试案例或者测试计划没有单元级别的变更控制。举例来说，我们的采访揭开了当前处理过程中的一个重大的失误，它导致了自动化的测试运行在测试数据库的非基线的版本上。这将给开发人员带来虽然是偶尔的，但却是严重的困难，它将迫使他们追赶虚幻的测试失败。除此之外，测试的分支建模将导致由于完成不同功能的测试具有相似的名称所带来的混乱。
最后，上述和变更管理和组件相关的缺点，意味着没有一种方法能够进行变更级别的影响分析。解决这些问题将极大地加快我们的测试处理过程，确保那些宝贵的资源被用在最能发挥其作用的地方。（这并不是说一定量的衰退测试是不重要的，是的，它的确很重要，但并不是对于每一个增量构建都重要。）
展开十分混乱
展开处理过程划分为若干个类别。本地的机器展开是需要开发人员完全手工完成的 —— 开发人员必须手工地升级他们的注册，将文件复制到构建代码，然后在本地运行产品进行测试。这依赖于软件“套件”的产品，即复制为二进制的形式，并且手工地（通过脚本）安装到开发人员的工作站上。更新处理过程也是手工的，并且有规律地发布新的套件。然而，当套件由于构建问题被延期的时候，开发人员就无法访问从其他人那里得到的对象，这就迫使他们必须等待那些构建被完成并且新的套件被展开之后才能继续进行他们自己的工作。数亿十亿字节的套件的全球展开是一件十分麻烦并且需要大量资源的事情。人们正在试图降低这一操作的复杂度，但是仍然存在同构建时间相关的瓶颈。
将产品展开到客户可交付的盒子上对于开发团队来说是一件十分神秘的事情。尽管这是一个与代码的展开高度相关的案例，就像用于公司的变更处理过程的监护人一样，但是变更和发布工程学开发团队还是应当非常注意在他们生成的代码上所发生的每一件事情。否则，当交付时出现问题的时候，他们就无法验证或者复制那些他们交付给客户的结果。
正如前面所讨论的那样，一家版本工程学公司的首要职责就是管理变更的流程。所有被版本工程学所支持的工具和处理过程都是和授权变更、跟踪变更、构建变更、并且最终将变更交付给内部或者外部的用户相连接的。最后，我们根据在构建和发布中的需要，从更广阔的方面对最初的讨论进行了重新组织。在完成这些操作之后，我们总结出以下这些成功的公司所共同具备的特点。
他们都具有上面所提供的支持
构建和发布团队经常缺乏消除那些中断变更的平滑流程所需要的权利。正如我们所看到的那样，那些变更是跨学科的，并且在传统上并不属于版本工程学要求的一部分。同样地，正如下面的建议中所讨论的那样，许多潜在的解决方案也将横跨那些领域。我将它称作“软锤”。最终，必须在工程学组织的最高层次上获得支持，从而强迫执行由版本工程学所设置的政策。
他们都加强了公司的一致性
试图支持多个工具和处理过程将破坏一支集中式团队所要实现的任何范围的经济。由于数据不能够平滑的从个体贡献者层次流动上来，所以这样做限制了在编程层次上管理公司的能力。这将导致个体成员、管理者、以及其他支持人员付出不必要的手工劳动量。由于每家公司都拥有不同的处理过程和工具，所以这样做限制了个体成员在不同公司之间移动的能力。当然，这种一致性并不是一夜之间就能够实现的。除此之外，在处理过程中必须要有足够的灵活性来允许开发团队以一种最能支持他们的方式开展工作。但是目标是不变的
—— 即定义一个清晰的、一致的、强迫的变更管理计划是一家成功的公司所需要的一项关键要素。
除了变更管理处理过程自身之外，一致性也存在于其他的领域之中。一致的展开机制的适当运用使得开发人员所遵循的处理过程和客户所遵循的处理过程相一致。同构建过程类似，开发人员构建的方式应当同“正式的”构建方式相一致。
他们都自动处理每件事情
或者，至少他们自动处理每一件能够被自动处理的事情。工具，并不是对任何一个问题都有效的解决方案，但是它们确实能够消除版本工程学团队和公司中的其他个体人员的大量的手工劳动量。这使得团队能够将关注点放在不容易被自动处理的更具有难度的问题上面。自动处理还能带来其他的显著的好处。特别地，自动处理能够确保处理过程被遵循，以及更多的迭代能够在同一个时间结构中被完成。
通常，自动处理能够去除处理过程中的浪费。精益的软件开发（一种日益受到欢迎的敏捷的开发方法）定义了七个核心原则，消除浪费位列第一。自动的处理过程、捕获韵律学、然后再对自动处理进行精炼，这样做能够使得开发团队不断地提高他们的方法，并且具有越来越高的有效性和可预见性。
他们都理解每件事情，并且有目的的进行操作
运行六至七次构建以“确保”其工作正常。为了更加有效地进行操作，版本工程学必须在处理过程的每一步被实际执行之前，就知道其预期的结果。他们必须能够随意地重头开始再造一个构建。他们也应该能够从零开始记录每一个步骤。为了使构建处理过程流线型化，他们必须对自己将要构建的系统的体系结构有一个清晰的认识。在系统的各个部分之间必须有一个确定的和备有证明文件的关系。除此之外，再没有其他方法能够安全地分割一个构建和测试处理过程。
他们都明确地记录每件事情
如果一支团队担起为一家公司权威地记录变更的责任的话，那么毫无疑问，文档资料将是该团队的核心工作。然而，这不仅仅是编写处理过程的文档资料，而是应当包括自动生成文档资料的踪迹。贯穿整个变更周期的可追溯性，是管理和满足诸如
Capability Maturity Model Integration （CMMI） 等不同标准实体的需求的关键。这些追踪及其相关的文档资料经常是作为稽核的一部分被手工地完成。一个大型的版本工程学团队为公司提供能够自动生成所有被要求的文档和韵律学的工具。
然而，一个被手工生成的文档也应当存在，作为一个记录公司变更流程的变更管理方案。变更管理流程（例如 IBM
Rational ClearQuest® 计划）的分支策略、命名约定、统一建模语言（UML）图表等，都应当被清晰而明确地声明。
他们都将变更管理处理过程当作任何其他的业务项目一样对待
正如我前面所假定的那样，版本工程学需要获得上述支持从而执行命令来强迫执行一致性。然而，这并不意味着版本工程学应当将任何事指定给任何人。相反，变更管理处理过程应当同任何一个其他的业务处理过程一样被精确地对待。它也应当以同其他任何一个项目所采取的管理结构被管理。这意味着他们应当将自己所做的工作视为提交给客户的业务服务一样。举例来说，每当我同开发人员一起工作的时候，他们都不断地将版本工程学视为提高效率的障碍。但是，我总是非常小心地告诉他们，作为我的客户，他们应当从我和我的公司这里期望结果。特别地，我告诉他们如果我不能使他们的工作更加轻松的话，那么我也无法开展我对自己的工作。因此，我为他们提供了一个报告问题的机制，使他们能够随时直接地同我进行联系，并且我还将我老板的联系信息提供给了他们。
以上，我谈论了清楚地记录变更管理处理过程的重要性。现在我们看到该处理过程的定义，以及改变它时应当遵循一个业务处理过程，并且其结果应当以同任何其他的业务处理过程一样的方式被追踪。任何类型的成功业务总是知道他们为什么会取得成功，所以他们能够促进下一步的成功；他们也总是知道为什么会失败，所以能够在此后加以修正。同样的逻辑也适用于版本工程学。
他们都具有世界级的工具和人员
一支团队的优劣最终还是取决于组成人员和管理人员的素质。工具能够帮助这家公司的工作人员达到他们为之奋斗的目标，但是如果没有高度的智慧来驾驭的话，工具本身并不能解决任何问题。幸运的是，这家公司已经具备了这种智慧。
不幸的是，对于上面所提到的抑制因素尚没有太多的解决办法。对于构建缓慢这样的问题，并不存在什么“银弹”；而且执行一个一致的、全面的和综合的变更管理处理过程并不是一件容易的事情。然而，仍然有许多短期的和长期的行动能够极大的提高该公司的变更流程。
我所建议的工具就是 —— 处于显而易见的原因 —— 所有的 IBM Rational 工具。这些工具所完成的任何事情都可以被手工地完成，或者由自制的工具来完成。然而，正如上面所解释的那样，同手工操作相比，使用现已存在的商业工具是一种更加高效的选择。
以下这十二项建议的排列顺序是随机的。其原因在于我们实在无法指定该公司应当首先执行哪一项建议，以及哪一项建议将会为该公司带来最大的回报。进一步的调查研究和分析将有助于澄清这些选项，但是许多选择还是最终取决于该公司是否愿意接受变更，是否希望授权版本工程学团队执行这些被提议的变更。
研究和记录系统的构建时间关系
分解现有的体系结构，使用一款诸如 IBM Rational Software Architect 这样的工具对其进行建模，并且捕获各个模块之间的详细的关系。根据需求重建体系结构，确保各个模块之间具有清晰和明确的关系。在建立过程期间应当不应当存在环形依赖。构建应当有一个清晰的顺序，并且有能力并行处理那些相互之间独立的构建片段。在发现处理过程期间
ClearMake 或者 ClearAnt 的使用，将有助于捕获现已存在的模块之间的关系。通过允许开发人员对由正式构建的对象视而不见而不是将它们手工地加载到他们的工作站上，将
ClearMake 作为套件交付处理过程的替代品来使用。调查重新定义基于系统体系结构发现物的 UCM 构成策略。
这样做有许多正面的好处。它将确保可靠的局部构建，从而使得开发人员有可能进行起飞前的准备工作。这样做将增强代码的可靠性，并且使得开发人员对于他们提交给综合流的工作更加具有信心。在正式级别上面进行可靠的构建，将大大提高开发的速度。进而，这将使得测试处理过程更加有的放矢。由于不再需要等待测试集合的完成，从而大大加速了正式构建的轮转。这样做还将减少设备的负载，将它们解放出来用来对其他构建进行测试，而这些测试是我们现在无法进行的。这样做将有助于消除目前所存在的“重复编译直到它工作为止”的思想情况。使用
IBM Rational ClearCase® MultiSite® 来分发获得的对象，将有助于消除自制的套件分发网络，并且消除构建完成时刻的带宽瓶颈。拥有一个详细的路线图将使得
CCB 能够基于对变更的分析制定出更好的业务决策。
记录并且理解对
Microsoft 开发平台的依赖
回顾并且记录那些代码依赖开发平台对象的地方。如果可能的话，确保代码能够在最新的 Microsoft
工具和开发平台上被构建并且/或者被运行。至少，要对构建和运行时刻展开的注册影响进行仔细地记录。
构建平台的脆弱性是一个重大的隐患。无法对开发人员的需要进行清晰的定义，使得开发人员构建的价值受到怀疑。构建和展开的注册影响都能够并且将会导致问题的产生。一旦这些影响被充分地理解，它们就能够被作为针对自动展开和构建的某些后续建议的组成部分而发挥其作用。除此之外，Microsoft
已经在 Visual Studio 2005 中从根本上改变了 SCM 提供者接口。这些变更使得诸如 IBM
这样的插件程序提供商有可能向 Studio IDE 提供更加丰富的综合。如果开发人员能够升级他们的 IDE
的话，那么他们将从这些更好的工具综合中受益匪浅。
回顾并且提高现已存在的分支策略
在没有完成详细调查的情况下，活动分支的数量看起来十分庞大。大部分公司拥有若干个在版本工程学级别上被管理的活动流，但是这家公司却拥有
100 左右的活动流。由于开发团队缺乏知识、技能、以及掌控自身的权利，从而导致了这种过多的分支在一个过高的级别上被管理的结果。我相信一个对于流策略的仔细回顾，将会得到一个更加健壮和简单的模型。
版本工程学团队为了赶上数量巨大的分支所付出的劳动量是令人惊愕的。许多也许并不应当进行的合并操作被进行，从而加大了版本之间和任务分支之间做出变更的复杂性。将工作流单一化的策略还将减少正在被构建的线路数量，并且使得活动版本更加活跃（请参见下文）。
巩固并且完成变更管理处理过程
充分发挥 ClearQuest 的全部功能。特别地，使 ClearQuest UCM 有效，从而充分利用
ClearQuest Test Manager 的优势，并且将可追溯性应用到从需求到测试案例和结果的全过程之中。调查并且记录当前的
ClearQuest 计划。添加功能以支持软件变更周期的所有步骤。添加类似代码回顾这样的步骤。在项目计划中以需求和/或任务的形式对活动进行定义。设置一个以软件为中心的需求工具，为项目提供一幅软件需求的清晰图像。使用需求和测试之间的关系将测试案例报告给需求覆盖。使用这些报告确保所有的需求都已经被测试所涵盖。它们还会被用来决定哪些测试案例是多余的，并且将这些多余的测试移除。自动地升级基于
ClearQuest 记录状态的项目计划。使通过 IBM Rational Method Composer
将变更管理处理过程发布到网上。消除各支团队之间手工的、小范围的通信。考虑应用一套组合管理工具（例如 IBM
Rational Portfolio Manager）使得公司的管理能够更好的得以进行。
完整的处理过程是成功公司的一个关键标志。一套自动追溯的机制将会有助于管理，并且有助于达到 CMMI
级别。自动的状态升级使得开发人员的生活简单化，并且使得管理层能够更加深入的了解开发公司的操作。将一些当前的状态报告和会议更换掉，将减少开发人员的管理负担。那些和清晰地对应需求无关的测试应该被消除，从而加快正式构建的轮转时间。利用一个常用工具管理团队的协同工作将确保通信不会被丢失或者错过。该公司已经拥有了
ClearQuest 和 ClearQuest Test Manager。使用这些功能将使得测试是被一个健壮的工具所驱动和追踪的，而不是来源于一组电子邮件和
Access 数据库。使用诸如 Rational Method Compose 这样的方法工具将处理过程发布到网上，将会使得每个人都知道变更处理过程中不同角色的期望是什么。使用
Rational Method Composer 使得处理过程能够被轻易地升级和重新发布。它还为工具和角色提供了专门的指导。
使用一款商业化工具自动处理构建处理过程
Implement IBM Rational Build Forge® 被应用到构建的自动化、执行和报告等组成部分。为开发人员设置事先准备好的测试构建。只有当代码发生变更时才进行构建。利用
Build Forge 的功能检测系统的配置，并且只有当配置正确时才在机器上进行构建。通过要求使用 Build
Forge 来执行构建和测试，消除了个体成员的本地登录访问。在每一次交付之前都要对其进行增量构建和测试。消除“爆炸式”方式的变更。通过使用
Build Forge 的并行构建功能对它们并行地进行构建，从而加快构建的速度。收集多少个构建正在运行以及它们何时失败的信息。使用这些信息来决定哪个区域的代码或者哪些新的特性最值得怀疑。使用
Build Forge 的时序安排功能，在交错间隙上运行正式的构建，从而限制拥塞等问题。将自动测试作为每个构建的一部分，并且使用同样的服务器选择机制，将代码展开到那些拥有正确配置的机器上面。
维持一个自定义的构建是有问题的。Build Forge 拥有强壮的、产业能力的安全性，并且时序安排内嵌其中。仅仅在配置良好的机器上运行构建，能够消除机器没有清除注册、或者机器不具有
Windows 或者 Visual Studio 的正确版本等问题。在代码发生变更时，Build Forge
通过自动检测来停止不必要的构建的这种功能，将减少硬件的资源负载。增量构建和更快的构建频率将会在下文中被进一步地讨论；它们将大有助于随时间推移而发生的质量变更。并行构建还将确保机器都被充分地利用。Build
Forge 能够检测出哪台机器是最忙碌的，并且适当的分发它的构建负载。事先准备的构建将允许开发人员在正式构建之前对他们所要进行的工作具有信心。开放构建和测试的盒子，将会消除开发人员进行测试构建的案例以及那些可能改变机器配置的测试，特别是被给定的对于注册设置和正在进行的注册的依赖。
改变版本发布频率
消除发生在孤立开发时的以四个月为一个周期的做法。取而代之的是更早更经常的整合。如果可能的话，开发人员应当从他们的任务团队中每天或者更加频繁地获取变更的信息。任务团队应当定期地将他们的工作拿出来分享给大家。通过后期绑定到任务分支的版本媒介物上稍微有一些复杂。这意味着开发团队必须十分小心，一定不要负责那些可能不会发布给他们的或者在他们之前就已经被发布的工作流。然而，整合的频率无疑是成功项目的一个指示器，这一点已经非常明确的。所以，找到一种使其工作的方式是至关重要的。
当我们评估版本处理过程的时候，我们要寻找一条稳定性曲线。在特性综合的时间间隔长达四个月的情况下，在每一个综合点上都会产成一个巨大的不稳定性峰值，然后它必须被开发人员追捕到，从而导致了任务流的延迟。至少来说，对于每一个任务分支，都应当经常地进行洞填补工作，但是我们还是必须找到某种方式，重新制定当前的计划，从而大大提高共享工作的频率。
加强测试处理过程
重做现已存在的管理执行处理过程。消除 Access 数据库系统。在每一个构建上面运行测试，包括增加的开发人员构建。使用
IBM Rational Manual Tester 来记录和追踪手工的测试，而这些测试在目前是由 Excel
电子数据表来完成的。由于 Silk 并不是适应 Eclipse Test & Performance
Tool Platform （TPTP）的，而且并不是针对 Eclipse 测试架构的插件程序，所以考虑将
SilkTest 替换为 IBM Rational Functional Tester。将 IBM Rational
PurifyPlus™ 和 IBM Rational PureCoverage® 添加到正常的测试处理过程之中。使用共同的变更处理过程来监控和操作测试的变更。当测试需要改变时，通过电子邮件消除自组网通知。保持测试上的韵律学覆盖所有需求，并且时刻保持测试上韵律学的执行。
在我们的访谈期间，现有的处理过程暴露出一个重大的问题。人们期望测试的基线版本在构建处理过程期间被执行，但是实际情况并非如此。这将导致开发人员必须追击这些随机的失败。遵循一个一致的处理过程，将会消除类似这样的失败。由
PurifyPlus 等工具所提供的额外的质量检查，将有助于最终产品的质量。运行 PureCoverage
将会验证所有的代码都能够被充分地测试。回溯到需求，将会消除无关系的测试，从而加速构建的轮转。随着综合的频率，测试每一个构建都将有助于减少不稳定的峰值。韵律学能够被用来发现代码的问题区域，这些代码一向存在问题并且需要进一步地分析。除此之外，韵律学将有助于制定出关于将版本媒介物中变更包包括进来的更好的决策。
授权版本工程学团队作为
CM 处理过程的拥有者
将版本工程学团队打造为变更管理处理过程的监护人。为处理过程收集需求，遵循同任何一个其他项目相同的业务处理过程。通过同任何一个其他变更相同的工具和处理过程集合，追踪处理过程的变更。依靠版本工程学小组的专家意见，定义公司的
ClearQuest 计划。要相信他们能够做出正确的决策。再一次指出，他们并不定义处理过程，而是保持它并且管理它。承认变更管理是一个公司的中心工作，因此，任何提高效率的处理过程（例如
CMMI）都将会直接影响版本工程学的工作，并且它们需要成为任何努力的关键贡献者。
作为一个小组，版本工程学在变更管理领域具备丰富的经验。要懂得充分利用这些经验的价值。正如前面所讨论的那样，通过明确地定义处理过程，从上述讨论中所获得的支持是公司成功的关键；建立一个单一的、中心的小组作为这个处理过程的拥有者，将确保所有人都工作在一个平台之上，并且理解他们所被寄予的期望。如果没有这个定义的话，有效地装配代码和变更这一复杂的任务将是不可能的。
记录并且集中 makefile
创造和所有权
开发一个共同的 makefile 结构和处理过程。让版本工程学负责管理 makefile，但是允许开发人员创建他们自己的
makefile。加强 makefile 的使用，即使是在 Visual Studio 项目中也是如此。
Makefile （或者 Ant 脚本、或者该公司所选择使用的其它格式）都是处理过程的核心。正因如此，它们应当是一致的，并且应当成为构建团队责任的组成部分。这将能够消除构建处理过程中的可变性，这些可变性将会严重地抑制我们上面所讨论的一些问题，例如增量的构建。
将其它的开发工作移植到共同的处理过程上面
将所有的源代码开发移植到共同的处理过程之中。
基于上面所讨论到的所有原因，拥有一个集中的、共同的、理解良好的处理过程，是实现经济实惠和消除浪费的关键。从一个管理的角度来看，拥有一个一致的处理过程集合，能够使得该公司更加有效地对自身进行监控。
记录并且捕获 Clarify
的桥梁代码
为 Clarify 和 ClearQuest 之间的桥梁记录并且捕获代码。
这一点是显而易见的 —— 两个关键业务工具之间的一个无正式文件记录的、晦涩难懂并且脆弱的链接，将把我们带入非常危险的境地。Clarify
或者 ClearQuest 打破了这个链接，从而抑制了也许改变这些工具以响应业务需要的能力。
对展开处理过程进行标准化和自动处理
以工具被展开的方式消除这些变更。简单化套件处理过程。记录并且理解这些代码在制造业处理过程期间，是如何被展开到新的硬件上面的。利用
ClearCase 的展开单元来追踪机制。记录 ClearQuest 中的构建和展开的输出。调查 ClearCase
中的存储套件，并且使用 ClearCase MultiSite 将它们复制到全世界。
让开发人员遵循同样的消除变更的处理过程，将会产生“就像在我自己的机器上面工作一样”的效应。版本工程学作为变更处理过程的监护人，应当理解在代码中发生的什么，这意味着应当理解它是如何进入一个
Product Lifecycle Management （PLM)）系统，并且最终在制造业中被操作的。在
ClearQuest 保存构建的记录，这样做可以报告和理解许多构建是何时以及如何被运行的。它还允许您看到建在位于处理过程中的什么位置（它们工作了么？它们失败了么？它们被发布到制造业中了么？）。ClearCase
中的存储套件具有一定的风险，这是因为它们过于庞大，但是无论我们是否能够保存部分的套件或者其他什么东西，我们都能够进行调查，并且将其用作一种复制的机制。
-
参与论坛讨论。
- 您可以参阅本文在 develperWorks 全球网站上的
英文原文。
- 现在开办了一个特别为 Rational Edge 的文章创办的
新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击
这里 开始。
-
全球 Rational 用户组社区
| 
