【IT168 技术文章】
本文来自于 Rational Edge：本文讨论了敏捷软件配置管理(Agile Software Configuration Management)的概念，一种适合于敏捷开发方法的 SCM 风格。文中还介绍了IBM Rational SCM 工具集如何实现敏捷软件配置管理，以支持敏捷项目。
并不久以前，敏捷开发方法，例如极限编程(eXtreme Programming，XP)、动态系统开发方法(Dynamic Systems Development Method，DSDM)，或 Scrum 作为新的且稍微有争议的软件开发项目的交付方法被引入。如今，敏捷开发实践，例如迭代开发、测试驱动的开发，和持续的集成成为了普遍现象，并且人们已经接受并采用它们作为另一种软件开发的方法。不论您的看法或经验是什么，您不能否认的是，敏捷开发项目可以并且已经证明能够成功，准时，并按照预算交付功能。
本文讨论了敏捷开发的具体方面 —— 敏捷软件配置管理，或简称“敏捷 SCM”的概念，一个精心设计的轻型 SCM，可以由软件开发项目使用和实践敏捷开发方法。作为此讨论的一部分，我还将关注企业级 SCM 工具集，例如 IBM Rational SCM 工具集，能够如何实现，以支持敏捷项目。
敏捷开发
大多数敏捷开发方法所共用的方法是让用户或客户直接参与并与之交流，并且在频繁的，短期的迭代(典型的为二到十二个星期)中进行功能开发。典型的是，在每个迭代的开始，敏捷团队会与客户商谈来确定新的特性或变更请求。这些由开发人员进行估计，并且随后，由客户为下一次迭代设置优先级，如图 1 中所示。任何还没有在迭代中实现的特性或变更请求将与所有新的请求一起保留下来，并且由客户为下一次迭代重新设定优先级。允许开发人员致力于当前迭代的请求，或者在必要时重构并简化现存的代码。这样做的意图是，保持设计的简单，并且防止不必要的特性膨胀。代码还是不断地集成的，并频繁地以很小的单位进行实现、测试及提交，这可以利用在提交时刻调用的自动化构建过程来检查集成错误。
图 1：在每个迭代的开始，敏捷团队会与客户商谈来确定新的特性或变更请求。这些由开发人员进行估计，并且随后，由客户为下一次迭代设置优先级。
如同所有软件开发过程，敏捷开发方法需要一个基于核心及支持团队的环境，一些在传统上称为软件配置管理，或 SCM 的东西。不幸的是，一些实践者将 SCM 看作是一个陈旧的且不必要的控制规程。但这是一个误解。虽然事实上过多的喝错误类型的 SCM 可以扼杀敏捷开发项目，但是敏捷实践，例如迭代开发和持续集成，如果没有 SCM 将不会成功这也是事实。
因此，对于这些类型的项目，您需要多少，以及什么类型的 SCM?要回答这些问题，让我们引入一个相对新的概念：敏捷 SCM(Agile SCM)。
敏捷 SCM
敏捷 SCM 概念本身可能是由 Brad Appleton 和 Stephen Berczuk 在他们的书 Software Configuration Management Patterns 中 和 SCM portal CM Crossroads 中被首次进行了详细地讨论。 2 其中一个观察是：
...配置管理在利用平衡且有效的 SCM 过程集方面成为关键的“支柱”并且也是敏捷开发方法的标准。“敏捷倡导者”着重强调在敏捷项目上应用瘦的及轻型的 配置管理(CM)，这将需要更少的打扰/入侵(Grady Booch 所谓的低摩擦)，以使敏捷项目能够成功，而与此同时配置管理有不能太小(由于过度反应)以至于导致项目失败。
与我刚才的观点一致的是，虽然敏捷项目上的 SCM 趋向于更加轻型且更少的可见性，但是 SCM 本身是此类项目的关键需求。也许不一致的是，大多数敏捷项目采用入门级或轻型的 SCM 工具，例如 CVS、Subversion，或 BitKeeper —— 这些工具有局限性但基本上拥有满足敏捷项目的功能。它们也是趋向于较小的影响并且重视开发经验的工具，而不是对一个严格控制过程的遵循。
然而，理论上，您没有理由不能使用 SCM 工具来支持敏捷开发实践。您当然不必要使用工具的所有特性，并且大多数工具允许某种程度上的过程定制化，从重量级到轻量级的，以及两者之间的任意程度。有了企业级工具，例如 IBM Rational ClearCase，一些组织总想使用所有的“突出特性”来定义重量级的 SCM 过程，只因为该工具提供支持。然而，这样的过程对满足您项目的需求是不必要的。要找到正确的过程和定制级别，您应该首先确定并定义您的需求，这意味着确切地了解您的开发过程是什么，或者应该是什么，然后确定 SCM 如何提供支持。
一般来说，SCM 是关于开发过程“管理”的，换句话说，SCM 允许项目保留控制措施，而与此同时又能够允许开发人员在过程中拥有创建的自由度。利用敏捷开发方法，开发人员拥有高度的自由和权利来实现变更。然而，持续集成和测试驱动的开发实践的一个结果是，它们实际上形成了一个规划良好的并且几乎自治的 SCM 方法。例如，在每个代码变更时，敏捷开发人员必须首先撰写一个单元测试，然后撰写足够的代码使测试能够工作，随后按照需要的重构以完成该变更。提交(或检入)代码变更，并且代码变更的单元测试成为集成套件中的一个部分。通过集成构建机制编译和执行完整的单元测试套件，可以直接可视化地看到变更的所有副作用 —— 所有找到的问题都能够立即修改。
在敏捷 SCM 中，该管理模型是日常开发活动的正常部分，并且因此对开发人员是相当透明的。要更详细地了解此管理模型，让我们看看 SCM 的一些不同的特征，以及如何典型地实现它们来支持敏捷开发方法：
分支。敏捷项目实现简单的分支策略，典型的是活动开发线(Active Development Line) 3 和版本预备线(Release Prep Line)。活动开发线由开发人员用来提交他们的变更并且持续集成构建通过此方法来执行。版本预备线是用于在客户使用之前稳定化或工程化一个版本的，通常不允许开发人员向它提交变更。
工作区。开发人员拥有一个单个私有的工作区，最初指向活动开发线最新版本的集合。在开发人员开始致力于新的特性或变更请求时，并且就在他们向活动开发线提交变更来检查集成问题之前他们的工作区以最小量更新着。
标签。如传统的 SCM 一样，标签放置在代码版本集合重要的里程碑上，在每个版本构建上至少有一个标签，以便在必要时能够重新产生构建环境。
构建和集成。成功的敏捷开发的关键因素是自动化的构建过程。构建过程监控关于提交的活动开发线，在一个较宽松的限期自动地执行集成构建和单元测试。该构建成功或失败的通知是敏捷团队中关键的通信因素。
变更控制。如早先讨论的一样，一个隐含的授权过程伴随着敏捷开发团队，授权开发人员做出基于客户优先级的变更，或者在必要时重构。请求要么记录在变更控制系统中，要么对于更不正式的项目来说，特别是在极限程序设计项目中，记录在卡片上或活动挂图上。
虽然这些 SCM 特性典型地处在敏捷过程中，但是它们很可能根据特定项目所需的敏捷程度而“调整”。例如，一些项目也许不能构建在每个提交上，取而代之的是计划一个单个的每日或每夜的集成构建。还有，项目不是独立存在的，它们通常是组织中许多项目中的一个。企业组织中常常混合有敏捷和传统的计划驱动的项目，并且因此一个已知的项目可能存在于特定的市场区段中。该企业环境常常是决定选择哪个 SCM 工具集并且所选工具集需要支持哪些额外的管理方面的最大的因素。
敏捷 SCM 和企业
如果您孤立地看一个单个的敏捷项目，那么它的 SCM 需求几乎肯定地可以由相当简单的工具集来满足。项目本身就可以使用并管理这样的工具集。然而，与其支持具体项目的工具集相比，大多数大型组织更喜欢将单个的 SCM 工具集标准化，并且围绕它开发组织过程。这样做有两个主要原因：
减少工具集及其过程的所有权的总成本
能够符合所期望的(或强制的)一致性或规章制度框架
所有权的总成本常常是主观问题，因为其包含许多可以计量的方面，例如许可、管理，和支持成本，以及其他主观方法，例如功能或可伸缩性。企业级工具集，例如 IBM Rational 工具集经常有更高的许可、管理，和支持成本(最初时是当然的)，但如果正确地实现了，这些企业工具集可以总体地提高组织能力。它们还拥有已证实的可伸缩性，一个单个的、统一的基础结构能够支持大型的，地理上分散的开发组织。如上面所提到的，这类工具的主要危险是试图使用超过所需的更多功能，这样会扼杀敏捷项目。需要建立一个组织的 SCM 框架，并且应该以某种可配置的方式来实现，以便满足不同项目的需求。
最近的行业法规，例如 Sarbanes Oxley、Basel II，和 CFR 21 Part 11 会向 SCM 过程施加繁重的管理成本，特别是关于变更控制的方面。虽然实践，例如“职责的分离”—— 不允许开发人员部署到实际的环境中 —— 应该实现，但是对敏捷项目严格强制实施变更控制会扼杀它们。然而，不满足这些法规的商业成本是巨大的，因此虽然敏捷项目可能希望避免不必要的管理实践，但是它们不得不在大多数情况下接受一些额外的开销。好的消息是，如果实现的正确，那么自动化的 SCM 工具集可以实现大多数的管理方面，使商家维持组织的控制，而又允许单个项目和它们的开发人员致力于有创造性地开发新的软件功能来解决商业问题。
