组织结构

　　有时，一个组织的结构还可以告诉您怎样插入应用软件到组件中。假设您的组织已经具体化了它的 Java 技巧并且将用户界面开发人员(HTML，JSP， JSF 等等)从他们的Java/J2EE 开发人员中分离开来。在这个案例中，您可以选定一个应用软件，将代码分离到这些行周围不同的组件中去(图 5)。

　　作为后台开发人员应该创建 EJB 解决方案，他们往往被应用软件吸引，前台开发人员提醒他们获取他们的数据。这仅仅是一个例子，告诉您检查应用软件以确保 ClearCase 中的构架上的重要部分被恰当组装是多么重要。

▲图 5. 组件　　

　　更进一步，有许多可供选择的方法能使 Java 应用软件使用通用的工具 JAR。例如，在 IBM®Rational®Application Developer 中，您可能在一个Web 项目的WEB-INF\lib目录中包含有效 JAR，或者使一个有效 JAR 作为 EAR 项目的有效成分。无论怎样，这些 JAR 变成分散交错的项目，您就会失去构架控制。

　　从另一方面说，如果您找到一个组件中这些通用工具 JAR ，JAR 的单个拷贝就在版本控制之下，这样您就可以迫使项目来使用那些 JARs，并且不包括将他们拷贝到他们工作区的方法。

　　您对这个方面关注越多，从长远来看对您就越有利。为您提供 ClearCase 组件特性，这样可以让您利用一个版本控制机制来分离片断代码，从而使您能够用一致的方式来管理代码。您应该充分利用这个特性。

　　工作区管理

　　最后，让我们检查一下工作区管理的方面。ClearCase 同时还提供了一个富含平行开发的特性。把 ClearCase UCM 看作是 ClearCase 和 ClearQuest 的顶层，它为工作区管理提供了一个系统的解决方案。流水线是用来分割任务的，UCM 项目是为分离的任务将可利用的组件重新聚集在一起。

　　通过将单个的 ClearQuest 活动与这套修饰过的用来满足那项活动的文件关联起来，您就可以获取一个变更集。那个变更集就代表这个修饰过用来满足这个变更的文件集。相反，每个文件的每一个版本都可以被追溯到这个活动，因此这个变更请求就可以引起变更。UCM 授予您管理您的项目的变更过程的最终能力。

　　在任何特定的时间，如果您只需要处理一个应用软件的一个开发工作就已经算很幸运的事了。但是事实上，在当今快速发展的软件开发领域，这是非常不现实的。需要紧急漏洞修补补丁来修补危机产品问题。同时，风险承担者不断地需要新的特性，因此就需要新地开发研究。ClearCase UCM 提供了这样地解决方案，允许您管理这个实体。

　　ClearCase 流允许您将一个离散的工作集从其它的工作种分离出来。UCM 项目允许您将必需的组件与一个流联合起来，从而提供完成工作所需要的环境。同时 UCM 项目向用户隐瞒了安装视图的复杂性。

　　UCM 项目还可以让您加强构架管理。例如，如果常用有效的 JAR 文件定位在一个组件中，这个组件在开发小组使用的 UCM 项目中应该被看作是一个只读组件，如图 6所示。另一个例子包括提供构建环境。通过为构件工作创建分离的UCM 项目，您可以提供所有只读源代码组件， 并且只允许这个构架过程更改储存构建目标的组件(如果您在ClearCase 中储存构建目标)。

▲　图 6. 利用 UCM 项目来加强构架管理概念

　　流策略

　　有很多流策略解决方案，而且每一个都有正面和负面的效应。至少，您的 ClearCase 管理小组需要建立一个流策略，并在项目运转时要坚持它。成功的 ClearCase 管理小组通过使用简单的白板或者电脑绘图纸的方法维持他们活动流(图 7)的“主要观点”。通过维持正在运行的主工作流的活动画面，您可以准确地决定是否应该以及什么时候在流之间传递基线，以及从哪个基线来创建新的流等等。

▲图 7. 主视图的一个例子

　　这篇文章的目的不是提供详细的流策略的方法，而是排除一些极端情况。首先，大多数管理人员会说任何时候将变更从发布中拉出来时需要很强的灵活能力。说起来容易，做起来却是难以置信的困难。从表明看，您可能倾向于将每个变更请求分离到到它自己的流上。这样的确给予您根本的弹性，因为：

　　这个变更对于那个变更请求是与其它所有变更相对独立的。

　　一旦您选择，您可以自由地将那个变更传递给适当地集成流。

　　然而，这却是一个 UCM 管理员的恶梦。这种方法为很多传递到其它各种不同流的传递创造了了需求，但是实在是很难管理。活动流太多而不能好好跟踪。

　　这个范围的另一个极端是一个完整的单个流概念。很显然依靠一个发布经理并不能提供所需的足够的弹性：

　　这造成了许多依赖性。

　　它并没有向您提供维持多项任务的能力。

　　这个良好的策略有时在中间，这篇文章将在接下来的部分检查一个类似的策略(在一个高层次)。

　　您现在又调查了两个使用 ClearCase UCM 特性的不同侧面，为您提供了一个良好的 ClearCase 基本结构，可以帮助您实现发布的目标。通过适当地将应用软件置于 UCM 组件中，您可以拥有利用受约束地方式提供组件来工作的能力。UCM 项目允许您装配那些必要的组件，同时还可以控制那些组件的使用权。

　　一个 UCM 项目还可以让您创建用来隔离工作任务的必要的集成流。除此之外，UCM 项目向用户隐藏了视图创建的复杂性。总之，一个流策略一旦被很好地定义，管理以及加强，就会为这个项目领导者提供一个构架为某次发布而管理工作。

▲图 8. ClearCase 如何支持 UCM

　　到目前为止，您已经审查了这四个方面在 ClearQuest 和 ClearCase 的执行中扮演的角色，使操作自动化并管理发布管理策略。 然而，到目前位置所提到的 ClearQuest 和 ClearCase 之间的唯一集成，是 ClearQuest 活动记录(已经将 UCM 包裹应用于其中)与组成变更集元素的相应版本的 UCM 集成。

　　项目经理和发布经理紧密配合工作，在他们相应的项目中共同计划变更，从而达到发布的目标。ClearCase 提供了 UCM 项目和流，这样可以允许开发人员将他们的工作分散到指定的目标发布中去。然而，目前您的策略还不能帮助管理这样的需求，即特定的变更管理对应特定的发布，因此只能对应一个具体的 UCM 项目。

　　在提出解决方案之前，这里有一个策略：对于每个应用软件，它们本身就是项目的一部分，而且这个项目包括发布中的一些功能的类型，此时您需要一个 UCM 项目和相应的集成流来分离工作任务。对于每个变更(有太多的流)的流和单个流开发(有太多的依赖关系)来说这是一个很好的办法。

　　针对一个具体的发布 ，何时创建集成流和相应的 UCM 项目来分散工作：

　　您应该为开发人员提供所需的工作空间。

　　它会给您便于管理的一定数量的流来处理。

　　然而，项目经理和技术领导者仍然有着令人畏缩的任务，即从策略上适当地将工作任务进行分配。随着工作期限的迫近，项目经理必须不断地评估还为完成工作地数量，并决定工作是否要直接跳转到接下来地发布。

　　您经常会遇到这样的可能性，即为了在工作期限内完成任务需要收回工作，这个策略只是看起来为了达到正常发布的目的提供了最好的环境。为了完成这个图像，您需要为开发人员指定方向，告诉他们在分配一个活动时应使用正确的 UCM 项目。

　　为了达到目的，可以在 ClearQuest 中 另外创建管理实体来帮助将所有连接起来。由于没有一个更好的名称，暂且称那个实体为发布单元。这个发布单元的任务是进行单独管理。它是这样操作的：

　　它向开发人员指明变更将在哪里发生的方向。

　　它允许项目经理和技术领导者检查他们尚未完成的变更请求的清单，并将他们分派到适当的发布但愿中(因此会指印开发人员到正确的 UCM 项目中)。

　　发布单元并不是一个银弹，而仅仅是一个组织机制，帮助推定事件将会在哪发生。您对从一个发布中分配一个变更到另一个仍然比较混乱，然后秘密地从一个流撤回一个变更集，移动到另一个流。无论如何，有了这个管理机制，至少您能很好地理解您拥有什么以及它存在的位置。

▲图 9. 一个发布单元是符合 UCM 的

　　当项目经理检查他们的迭代计划时，以及为了满足发布预定日期安排工作来完成他们的迭代时，他们可以将每个变更请求分配给它适当的发布单元。这个发布单元于特定的 UCM 项目是相关联的。因而，当开发人员检查她分配的活动时，每个活动都与一个发布相结合，这就说明对于特殊的 UCM 项目有一个具体的分配。发布单元

　　结论

　　为了达到正常预定发布策略的目的，调解项目和开发工作是相当复杂的问题。ClearQuest 和 ClearCase 提供构建板块，让您自动操作自定义的发布策略，如图 10所示。

▲图 10. 蓝图：一个自动化的、自定义的发布策略

　　如果您记住以下几点，在达到您发布目标上，您将拥有比您实践而获得更好的方法：

　　注意这篇文章中讨论的四个方面

　　利用 ClearQuest 的功能有助于您管理这个复杂的事务

　　将您的流策略与您的 ClearQuest 实现连接起来