敏捷 SCM 和企业

        如果您孤立地看一个单个的敏捷项目，那么它的 SCM 需求几乎肯定地可以由相当简单的工具集来满足。项目本身就可以使用并管理这样的工具集。然而，与其支持具体项目的工具集相比，大多数大型组织更喜欢将单个的 SCM 工具集标准化，并且围绕它开发组织过程。这样做有两个主要原因：

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

        所有权的总成本常常是主观问题，因为其包含许多可以计量的方面，例如许可、管理，和支持成本，以及其他主观方法，例如功能或可伸缩性。企业级工具集，例如 IBM Rational 工具集经常有更高的许可、管理，和支持成本（最初时是当然的），但如果正确地实现了，这些企业工具集可以总体地提高组织能力。它们还拥有已证实的可伸缩性，一个单个的、统一的基础结构能够支持大型的，地理上分散的开发组织。如上面所提到的，这类工具的主要危险是试图使用超过所需的更多功能，这样会扼杀敏捷项目。需要建立一个组织的 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 或 IBM Rational BuildForge来实行。

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

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