• 敏捷开发
• 敏捷 SCM
• 敏捷 SCM 和企业
• 用 IBM Rational 工具集实现敏捷 SCM
• 适合于敏捷方法的过程
• 注释

本文来自于 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 工具集标准化，并且围绕它开发组织过程。这样做有两个主要原因：

• 减少工具集及其过程的所有权的总成本
• 能够符合所期望的（或强制的）一致性或规章制度框架

最近的行业法规，例如 Sarbanes Oxley、Basel II，和 CFR 21 Part 11 会向 SCM 过程施加繁重的管理成本，特别是关于变更控制的方面。虽然实践，例如“职责的分离”—— 不允许开发人员部署到实际的环境中 —— 应该实现，但是对敏捷项目严格强制实施变更控制会扼杀它们。然而，不满足这些法规的商业成本是巨大的，因此虽然敏捷项目可能希望避免不必要的管理实践，但是它们不得不在大多数情况下接受一些额外的开销。好的消息是，如果实现的正确，那么自动化的 SCM 工具集可以实现大多数的管理方面，使商家维持组织的控制，而又允许单个项目和它们的开发人员致力于有创造性地开发新的软件功能来解决商业问题。

用 IBM Rational 工具集实现敏捷 SCM

让我们来考虑，对于使用 IBM Rational 工具集的敏捷项目来说，管理的严格性和灵活性之间的平衡如何能够被达到呢？

一个普遍的误解是企业级 SCM 工具集 —— 例如 IBM Rational 工具集 —— 不能用于支持实现敏捷开发方法。这些工具集中所提供的重要功能是来支持许多不同的类型和大小的开发环境的，因此，确定该功能的哪个要素应该使用是不容易的，并且存在的一个风险是，对 SCM 过程将进行过渡的设计。目前，在 IBM Rational SCM 工具集中还不存在现成的敏捷 SCM 配置。取而代之，留给工具集实施者的是找到满足其需求的适当的配置。

好消息是，在 IBM Rational 工具集的支撑下，许多组织已经设法找到了这种配置，并且将成功地实现敏捷开发方法。从观察来看，有许多这些项目所共用的最佳实践。虽然这些最佳实践不是绝对的，但是它们应该足以给您一个框架及实现您自己的敏捷 SCM 过程的起始点。它们可以如下概括为：

实现一个简化的分支策略。敏捷项目实现简单的分支策略。在 Base ClearCase 和 ClearCase UCM（统一的变更管理，Unified Change Management）中，分支（UCM 术语中的“流”）可以很容易且很廉价地生成。因此经常会有这样的趋势，定义比确切需要的更复杂的分支策略。敏捷项目积极地鼓励持续集成和重构，但是开发人员孤立于分支上，那么将出现有问题的或复杂的合并操作。这在命名空间重构（重命名、添加，或删除文件或目录）的情况下尤为正确。因此，大多数敏捷项目实现一个特定的分支，作为活动开发线，并且开发人员直接处理的上面的内容。在 Base ClearCase 中，这要么是主分支，要么是具体的项目集成分支，在 UCM 中，这是 UCM 项目的集成流。要隔离一个版本的环境，也会实现一个版本准备线。通过创建一个拥有可以放置在活动开发线之下的候选标签（或者 UCM 基线）的版本分支（或 UCM 流）来实现。该标签将手动地生成 —— 或者更可能自动化地 —— 作为集成构建的一部分。说明此结构的图如图 2 所示。

图 2：要隔离一个版本的环境，通过创建一个拥有可以放置在活动开发线之下的候选标签（或者 UCM 基线）的版本分支（或 UCM 流）来实现一个版本准备线。该标签将手动地生成 —— 或者更可能自动化地 —— 作为集成构建的一部分。

敏捷项目不但提供简化的分支策略，它还倾向于配置 ClearCase 默认为“无限制的”检出模型。这允许开发人员检出和检入一个活动开发线上任意点上的文件（虽然如果在此期间另一个开发人员也检出和检入同样的文件，应该对这些进行一些合并）。默认的 ClearCase 模型对于第一次的检出是“受限制的”。这意味着，您不需要必须合并而保证能够将元素检入回去。然而，这还意味着，其他人不能检出受限制的元素，直到您将其放回为止，检出无限制元素的人必须等待在合并之前您将该元素检入回去。这种方法真的违反敏捷原则。

　使用快照视图开发人员工作区。如果开发人员将要致力于单一的分支，那么不用选择动态的视图。动态视图的能力在于当它们监测的分支更新时，它们可以自动地更新自己。因此，如果许多开发人员在单个的分支上加上动态的视图，那么在它们的工作区中几乎不能控制或隔离。虽然开发人员分支不能实现，如我们已经讨论过的，但这可以导致其他的问题。因此敏捷项目会实现快照视图，从中开发人员可以更新他们的工作区来从其他开发人员那里引入变更。在实践中，这给予开发人员足够的控制和隔离。

　自动化构建过程。单个的分支开发和增量的的检入只有在频繁地执行自动化的构建和测试时才能够实行。大多数敏捷项目将它们的构建过程配置为在每个开发人人员的检入之上执行。除了编译代码，这种构建过程还验证新的代码，用以观察代码是否符合预定义的编码习惯，并且在必要处执行单元测试。在敏捷开发方法中，该实践常称为持续集成。其预期的结果是为了尽早地暴露集成问题，以便容易地处理，以及在项目的每个阶段都有建立好的、测试了的，以及可能的可发布的构建。持续集成常常与测试驱动的开发实践杂乱的链接在一起。这是因为开发人员需要对其代码的所有方面实现单元测试来验证构建已经编译了，以及符合最低水平的功能质量。在 ClearCase 术语中，敏捷项目构建过程用于监控集成分支（或 UCM 流）以及在检入时执行构建教本。这由构建执行工具，例如 CruiseControl（http://cruisecontrol.sourceforge.net）或 IBM Rational BuildForge（http://www.ibm.com/software/rational/buildmanagement/）来实行。

　执行并再利用预构建好的二进制码。构建任何相当复杂的软件应用程序都会花费时间，从几分钟到几小时。在敏捷项目中，开发人员将会经常交付并集成小的变更，因此很显然他们不可能在得到反馈之前等待两小时完成构建操作。为了避免这种情况，敏捷项目“执行”并再利用预构建好的二进制码，并且只有再必要时重新构建整个系统（例如，每夜或每周）。有许多方式来执行二进制码。ClearCase 常常用于执行二进制码，标签或基线设置在相关的版本之下，来指示可复用的二进制码的复合集。对于 C/C++ 项目，ClearCase clearmake 实用程序也拥有一个避免构建的机制，可以用于将大部分这种执行自动化并再利用过程，虽然没有证据证明敏捷项目使用此机制。对于 Java 项目，另一种方法是，在相关管理工具，例如 Ivy（http://jayasoft.org/ivy）或 Maven（http://maven.apache.org）中执行预构建好的库。当项目再利用大量开源组件时，或在传递相关性方面存在问题时（也就是，库依赖于其他的库）这一点尤为适当。

　作为复合的应用程序而发布。当说到发布应用程序时，试图发布所有的文件，而不是发布个别集合。大多数敏捷项目更喜欢每次部署全部的或复合的应用程序，而不是只部署已经变更的个别的文件。虽然这不是硬性规定，每次以同样的方式发布全部的应用程序趋向于使过程更加可重复并且防止文件丢失所导致的问题。该实践对敏捷项目比对高要求形式的项目更为重要，因为它们在每次迭代之后生成可执行的、可测试的，并且可发布的应用程序。很明显，这依赖于应用程序的目标环境。如果是 Web 门户，那么该方法很好，但如果是一个消费者应用程序（运行在，比方说，Microsoft Windows 上），那么完整的版本不可能每次都给客户，所以就需要每次一个补丁。

　限制 MultiSite 技术的使用。分布式的敏捷项目需要无限制的对单个代码行的访问。ClearCase MultiSite 技术从站点到站点复制完整的数据库。为了避免每个站点所做出的变更的冲突，其实现了一个所谓 mastership（主权） 的概念。这意味着如果一个项目在多个站点上开发，并且开发人员正共用同一个分支，那么每个开发人员在提交变更之前要请求主权。有许多方法来处理这件事（包括创建基于站点的集成分支），但它们都增加了额外层次的复杂度，并且会减慢开发过程。出于这些原因，敏捷项目倾向于避免 MultiSite 技术。这就是为什么开发了 ClearCase Remote Client (CCRC) 技术，它允许基于脱离单个服务器的分布式开发。CCRC 的第一个版本限制了功能，然而，从版本 7.0 开始，它将对大多数分布式项目提供足够的功能。因此它应该成为进行分布式灵活项目的推荐方法。图 3 中的屏幕快照说明了工作于 Eclipse 环境中的 ClearCase Remote Client。

　　

　　　　　　　　　　　　　 图 3：工作于 Eclipse 环境中的 ClearCase Remote Client

避免 ClearQuest 变更控制的过度自定义。实现一个开放的或可定制的变更请求工作流。IBM Rational ClearQuest 工具提供非常强大且成熟的变更和缺陷跟踪工具。虽然许多使用 ClearCase 的敏捷项目已经完全避免使用 ClearQuest 的了，但是越来越多的项目在着眼于 ClearQuest 以及 UCM，看看是否可以用于帮助满足组织遵从和法规的需求。的确，ClearQuest 可以在自动化获取、划分优先级，及变更请求和特性储备的分配上占有地位，如我在本文开头所提到的。然而，过多的过程强制或过小的管理会令开始致力于新的变更任务的开发人员感到时间紧迫。如果不小心实行，这会严重地减慢整个开发过程并减少敏捷项目的生产率。为了避免这一点，敏捷项目实现轻量级的或可定制的 ClearQuest 变更请求工作流。当 ClearQuest 用于整个组织中时，这是尤为恰当的。在那些组织中的一些项目可能会需要更多的控制和管理，许多会嵌入 ClearQuest 工具中。然而，敏捷项目可能不需要或期望同等程度的过程控制和管理。在这种环境中工作的组织通过令变更请求工作流可以让每个项目来配置而取得成功。然而，这种实现需要对 ClearQuest 工具和不同项目过程需求的详细了解，并且应该不容易着手。

适合于敏捷方法的过程

在本文中，我已经讨论了敏捷 SCM 的概念以及如何利用 IBM Rational ClearCase 和 IBM Rational ClearQuest 来实现的最佳实践。希望该讨论可以使您确信，可以找到并实现合适的过程来支持敏捷项目。值得注意的是敏捷 SCM 的实现不是只限于敏捷项目的。有许多项目不认为自己是敏捷的，但已经有类似的 SCM 需求。这些趋向于较小的 IS/IT 项目，类似环境的配置会非常实际。但值得注意的是甚至是较大的项目也可以通过实现更轻量级的且精心设计的 SCM 过程，例如这里所介绍的，来得到一些东西。特别是，构建自动化（包括编译和测试）、预构建好的二进制码的执行，和复合发布的实践可被所有项目采用。

没有理由说企业级 SCM 工具集，例如 IBM Rational 工具集，不能用于支持敏捷开发方法的实现。关键是，定义并实现一个着重于支持，而不是限制，敏捷团队的敏捷 SCM 过程。对于这样的团队，找到正确的管理模型会是一个棘手的训练，但是一般建议从更开放的过程开始，只在必要时实现限制。反馈也是敏捷开发方法的必要部分。SCM 可以有助于此反馈机制的一种方式是通过自动化的构建和测试（及部署）过程。因此推荐您投入大量时间关注您整个过程中的这个方面。

注释

1 要了解敏捷和传统的开发方法相对比的优缺点和成功方面的讨论，请参见 Barry Boehm 和 Richard Turner 的优秀书籍，Balancing Agility and Discipline: A Guide for the Perplexed: Addison Wesley 2004 年。另外，要了解关于敏捷开发方法的最新讨论和案例研究，您可以访问并订阅The Agile Journal（http://www.agilejournal.com）。

2 Stephen P. Berczuk 和 Brad Appleton，Software Configuration Management Patterns. Effective Teamwork, Practical Integration。 Addison Wesley 2003 年。另参见 Brad Appleton et al.，Streamed Lines: Branching Patterns for Parallel Software Development。PLoP Conference：1998 年。http://www.cmcrossroads.com/bradapp/acme/branching/

3 参见 Appleton，1998 年，Op. cit。

4 要了解更多关于如何为敏捷项目设立自动化的构建环境的信息，请参见 Kevin A. Lee，IBM Rational ClearCase, Ant and CruiseControl。The Java Developers Guide to Accelerating and Automating the build process。 Addison Wesley 2006 年。