用 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 可以有助于此反馈机制的一种方式是通过自动化的构建和测试(及部署)过程。因此推荐您投入大量时间关注您整个过程中的这个方面。