Jazz 通过允许团队在软件中实施最佳实践,从而减轻流程负担。流程增强功能内置在从开发环境一直到存储库的整个 Jazz 中。
本文的目的是帮助您开始使用 Jazz Team Process 组件。下面小节是您将了解的内容的摘要。
下面一节将介绍 Team Process 用户界面 (UI) 的重要元素。由于需要了解以下主题,因此没有提供有关如何使用该 UI 的大量详细信息。
下面一节您将了解有关 Jazz Process 组件能为团队做些什么及其如何工作的更多信息。将介绍的内容包括用于定义和自定义项目、定义团队和您希望教会 Jazz 的流程的一般概念、术语和机制。
掌握 Jazz Team Process 概念和用户界面以后,您将了解用于指定项目的流程和项目中的团队如何自定义该流程以适应特定需要的机制。
在继续之前,我们假设您已经阅读了 “Jazz 入门教程”。特别是,您需要知道如何连接到 Jazz 存储库并使用 Create Project Area 向导创建项目区域。
下面是作为 Jazz Team Process 组件一部分的主要对话框、视图和编辑器的描述和屏幕图像。 这里没有对它们进行详细的描述,而只是为本文的其余内容提供上下文。“Team Process 自定义练习” 部分将介绍有关流程用户界面的更多内容。记得 “Jazz 入门教程” 在标题为“设置项目”的部分中介绍了用于创建项目区域的用户界面。下面引用了一些将在稍后进行解释的流程术语。
Process 透视图主要用于流程管理操作、指定和自定义项目及其团队的流程,以及创作流程模板。
Process 透视图
多个 Jazz 透视图中包括了 Team Artifacts 视图,因为它对于所有 Jazz 用户都非常有用。该视图显示用户所连接到的项目区域、用户有权访问的存储库、用户所属的团队区域,以及用户的 Jazz 工作区等等。工具栏具有用于创建新的项目区域或连接到现有项目区域的操作。可以对该视图的内容进行过滤。
Team Artifacts 视图
此视图在控制流程已参与某个 Jazz 操作时提供信息。此视图出现在 Process 透视图中,并将在需要时自动在其他透视图中打开。其内容可以是信息性的,或者在发生了流程冲突的情况下,建议用户避免此情况,阻止用户完成任务,或者允许用户否决该流程冲突。
Team advisor 视图
此视图显示用户所连接到的项目区域和其中的团队区域的层次结构。通过打开项目和团队区域编辑器,可以对这些区域的流程进行自定义。这允许团队成员了解和调整他们的流程。
Team Organization 视图
New Project Area 向导和 Connect to Existing Project Area 向导
这些对话框用于定义新的项目区域和连接到现有的项目区域。它们出现在 Team Artifact 和 Project Area Explorer 视图的工具栏上。
Project Area 向导
连接项目区域向导
这个多页面的选项卡式编辑器用于在创建项目区域之后修改项目区域。
概述 页面用于描述项目,定义全局团队成员,以及定义项目的迭代结构。迭代结构包括每个迭代的开始和结束日期、每条开发线的当前迭代,以及产生可交付件的迭代集合(例如,此集合确定工作项的“planned for”字段中有哪些迭代可用)。项目区域的流程基于所确定的流程模板。下面的示例使用了 Sample Process 模板。此页面提供了概述流程模板的简要说明和导航到流程模板详细文档的超链接。
项目区域编辑器
(此图像进行了等比例缩小)
Process Specification 页面用于配置流程将在各个迭代期间对各个角色具有什么行为。此规范使用 XML 进行描述。
Outline 提供其内容的结构化视图。
Work Item Categories 页面用于添加和删除工作项分类,并将它们与特定的团队区域相关联。与工作项分类相关联的团队区域将确定用于控制在该分类下创建的工作项的流程。例如,团队区域流程配置可以指定必需的工作项属性。
此向导将创建新的团队区域,并且可以从 Project Area Explorer 和 Team Artifacts 视图中所选的项目区域和团队区域中作为上下文菜单使用。
创建团队区域对话框
此编辑器的外观与项目区域编辑器非常类似,并用于定义团队成员,选择开发线(稍后将对此进行详细描述),以及可选地自定义团队的流程。
团队区域编辑器
概述 页面用于定义团队成员及其角色,指定开发线,以及浏览、修改和配置团队构件。
Process Customization 页面用于修改或扩充团队区域从其父项目区域及团队区域继承的流程。
请注意,可以在项目中为团队成员定义一个或多个角色。
此视图用于创建或修改在创建新项目区域的过程中选择的流程模板。
Process template explorer 视图
要创建新的项目模板,可以在该视图中右键单击某个存储库连接,并从上下文菜单中选择 New>Process Template 以打开 Process Template 向导。向导完成时将打开 流程模板编辑器。此编辑器的外观非常类似于项目区域编辑器。
Jazz Team Process 组件帮助团队一致地执行已达成一致的流程,它不定义流程。实际上,此组件是独立于流程的。更恰当地说,它在 Jazz 中保持持续的存在性,随时准备建议或强制执行团队已采用的流程。流程在 Jazz 中出现得很早。当在 Jazz 中定义项目和团队时,您就有机会开始指定流程。当然,可以修改流程以满足不断变化的改进需要。Jazz 包括一些示例流程,可以对其进行采用和自定义以适合您的需要。可以为 Jazz 提供根据团队需要而定制的新模板,并且可以与其他人共享流程。预期随着时间的推移,为了所有人的利益,软件开发方面的最佳实践将在 Jazz 中变得可用。
在继续之前,您可能希望阅读 “Jazz 平台技术概述” 中有关 “Team Process” 组件的部分。其中介绍了 Team Process 组件的体系结构。该部分内容不是非常长,很值得一读。
为了充分掌握本主题,您应该使用 Sample Process 模板定义一个新的项目区域。后面将会频繁引用这个流程模板。如果之前还没有这样做,请参阅 “Jazz 入门教程” 中的“设置项目”。请注意,只有拥有 admin 系统权限的用户才能创建项目区域。您将需要作为用户 ADMIN 登录,或者将此权限分配给您的用户 ID。(请参阅:
侧栏:系统权限)。
非常抱歉,这部分内容很长。如果您希望揭开应用 Jazz Team Process 的秘密,则需要有一些耐心!你应该会发现这是物有所值的。
下面让我们更详细地研究一下项目区域和团队区域。
Jazz 允许实现丰富的项目和团队结构,以支持小型团队(甚至是一个人的团队)到开发和维护各种各样的产品可交付件的大型团队。 项目结构使用项目区域来定义,并且通常包括一个或多个团队区域。到现在为止,您应该了解到项目区域和团队区域在 Jazz 中起着非常重要的作用。事实上,所有 Jazz 组件都在这些区域的上下文中操作。流程是在项目区域中定义的,并且可以在团队区域中做进一步的自定义。实际上,项目区域可能包括许多团队区域,因此,Jazz 允许实现团队区域的层次结构。每个团队可以通过添加和/或覆盖父团队的流程来自定义自己的流程。父团队可以禁止流程覆盖。项目成员(在 Jazz 中称为用户或团队成员)可以是多个团队的成员。在此情况下,该用户必须遵守他/她参与的每个团队的流程。
就其计划及其承诺的可交付件而言,项目可以非常简单或非常复杂。已经投入应用的已有项目很可能具有以下活动的开发线。
- 一个或多个已交付版本的维护。
- 新版本的开发。
- 将来版本的探索性开发。
所有这些开发线并行工作并分别处于不同的状态。此外,每条开发线将具有一个或多个迭代,其中将交付某一组可交付件或功能改进。为了涵盖所有这些开发线,将向每项工作分配一个或多个团队。大型项目可能具有丰富的团队层次结构。用户可能具有多项任务分配,要求他们在多个团队工作。有些项目成员可能不属于任何特定的团队(例如,总体项目负责人),但却是项目的活跃成员。项目采用的流程不会统一地应用于所有开发线。团队需要自定义该流程以满足其特定的项目职责。Jazz Team Process 组件满足所有这些需求。
项目区域指定一组迭代,迭代是项目生命周期中的间隔,迭代可以分解为子迭代。
让我们继续探索项目区域的组织和所涉及到的术语。
下面是某个项目区域中包含的示例层次结构。这些元素的含义是什么以及它们如何应用于项目呢?
可以定义任意数量的迭代,并将它们嵌套到任意深度。
开发线: 开发线表示项目的一个结构元素,此元素拥有一组可交付件和用于产生这些可交付件的计划。开发线中定义了迭代层次结构。开发线可能具有特定的流程要求。例如,同时具有新产品版本开发和当前产品维护的项目可能在单独的开发线中定义这两组工作,因为这些工作具有不同的交付计划,并且可能具有不同的流程。
迭代: 迭代将开发线划分为可能具有显著不同的特征的单独周期。在此例中,该团队首先将其开发线划分为对应于不同项目生命周期阶段的迭代。例如,项目可行性阶段设法基于项目需求来确定什么将是可行的。此阶段的流程非常灵活,预期将丢弃某些或者可能丢弃其所有成果。相反,项目的准备交付阶段高度受控,并设法实现稳定性和质量,其流程可能要严格得多。
然后该示例团队将项目阶段划分为与里程碑对应的迭代。里程碑是具有实际可交付件的工作迭代,其持续时间可以达数周。
最后,该团队分解每个里程碑,以配置每个里程碑的生命周期。例如,将该团队的里程碑可交付件提供给客户以便评估,因此他们在每个里程碑中有一个开发阶段和最后完成阶段;后者具有更严格的流程要求。
可以想象,跨越很长时间周期的大型项目可能使用这些元素来定义详细的迭代层次结构。
下面是一个示例,其中显示了 Eclipse Way 流程模板提供的缺省迭代。
流程迭代摘要
所有这一切的目的是为了定义项目结构,以便能够在不同的时间点微调流程。在任何时间点,项目(更明确地说是开发线)处于某个特定的迭代中。可以根据该间隔的需要自定义项目的流程。这暗示着需要定义哪个项目迭代当前是活动的。这使得 Jazz 可以确定当前迭代,从而确定要在任何给定的时间点强制执行什么流程。在项目的可行性阶段期间,流程可能是轻量级的,而该里程碑的最后阶段可能需要严格的流程。在上面的屏幕快照中,当前活动的迭代通过邻近该迭代的亮蓝色箭头进行区分。
最后,可以在项目区域中定义项目的流程。稍后将对此进行更详细的探索。
下面总结一下项目区域:
- 项目区域包括开发线和可分解为子迭代的迭代结构。这些元素为团队随时间推移而定义不同的流程要求提供了基础。
- 每条开发线将具有自己的一组迭代,其中一个迭代是当前迭代。 这允许在项目区域中进行并行开发。
- 可以在项目区域中定义对项目做出贡献或扮演特定项目角色的用户。
- 项目流程以 XML 形式指定,并且可以针对不同的迭代进行自定义。
- 由于项目区域是所有用于该项目的 Jazz 项的根,因此不能将其从存储库中删除。可以对项目区域存档,从而将其置于休眠状态。
下面讨论一下团队区域以及它们如何在项目区域中工作。
在 “Jazz 入门教程”中,当您定义项目区域时,Create Project Area 向导自动创建了一个团队区域(这是因为所选择的 Eclipse Way Process 模板的初始化活动被定义为创建一个团队区域)。团队区域提供以下功能:
- 定义团队中的用户(团队成员)并指定其角色。
- 定义团队正在参与的开发线。
- 根据团队的需要自定义项目流程。
Jazz 允许实现团队区域的层次结构,以适应更复杂的项目和在项目中具有不同需要的大型团队。项目的任何参与者都可以参与一个或多个团队区域。我们还没有介绍流程是如何定义的,但是团队区域将继承父(可以是项目区域或父团队区域)流程。团队区域可以自定义父流程,并在允许的情况下覆盖父流程的部分或全部内容。
项目区域可以定义一组角色。
角色定义 (XML)
项目区域中定义的两个示例角色。
通过配置前提条件和后续操作,可以强制团队流程的所需行为。前提条件在运行操作(例如交付代码)之前进行检查,并且可能阻止操作执行。后续操作在运行操作之后运行,并且可能做出附加的自动化更改。例如,在某个工作项已解决时,后续操作可以自动创建验证任务。
通常,不存在统一地适用于项目中所有人的单个流程,也不存在适用于所有项目阶段的单个流程。可以将流程选择性地应用于整个项目、特定项目团队,并且可以在项目生存期的不同迭代过程中改变。通过指定是否可以手动否决前提条件,您还可以配置将强制执行流程的严格程度。在定义要检查哪些前提条件、何时检查这些前提条件以及这些前提条件适用于何人时,Jazz 流程组件非常灵活。
前提条件是使用 Eclipse 扩展点机制和 Java 代码来创建的。前提条件可以在 Jazz 服务器和 Jazz 客户端上执行。稍后我们将讨论客户端与服务器前提条件之间的区别。Jazz 附带了一个可供使用的前提条件集合。前提条件在项目区域中使用 XML 来指定。可以为特定团队或特定迭代自定义该前提条件集。例如,作为接近完成的项目,团队可能希望在准备交付产品时指定附加前提条件或不得否决现有的前提条件。Jazz 适应所有这些要求。
Jazz Team Process 组件依赖其他组件的流程支持。
支持流程意味着组件邀请前提条件和后续操作参与由该组件执行的所选操作。还可以将后续操作配置为在每当某个组件产生某种类型的事件时运行。所有 Jazz 组件都支持流程。下面查看两个由 Jazz 组件实现的流程支持的示例,以及可用于这些组件的一些前提条件。
Work Item 组件为工作项保存操作提供流程支持。这允许实现可验证工作项内容的前提条件,以确保完整性和其他要求。针对工作项保存的前提条件之一是允许您定义在保存工作项之前必须填写工作项中的哪些字段。如果某个必填字段不完整,则保存操作将停止,并在名为 Team Advisor 的视图中提供详细信息。
Team Advisor - 工作项保存
Jazz SCM 组件为其交付操作提供流程支持。这允许在将内容交付到存储库并与其他人共享时应用前提条件。内容交付是软件项目中的重要步骤,因为这里的问题会导致构建和运行时错误。其中一个 Jazz 交付前提条件防止提交具有编译错误的 Java 代码。如果交付其更改的项目中存在编译错误,则停止交付操作并通知用户。带有关于该交付问题详细信息的通知出现在 Team Advisor 视图中。
Team Advisor - 代码交付失败
这只是两个示例。Jazz 扩展人员可以定义附加的前提条件。可在 Jazz 扩展人员定义的前提条件中实现的检查类型几乎不存在限制。
新的操作和前提条件一直在不断添加到 Jazz。此列表是一个代表性的集合,但是不一定详尽。有些操作没有任何前提条件,但是在定义对这些操作的访问时,前提条件非常有用(请参阅:角色与权限)。
源代码控制交付操作
- 禁止编译错误前提条件
- 建议团队成员不要交付具有变异错误的代码。
- 禁止未使用的 import 前提条件
- 建议团队成员不要交付具有未使用的 import 语句的 Java 代码。
- 在交付代码时要求工作项前提条件
- 建议团队成员将某个工作项与每次代码交付相关联。
工作项保存操作
- 工作项需要属性前提条件
- 建议团队成员在保存工作项之前完成其中的某些字段。
- 创建验证工作项前提条件
- 当以 Resolve/Fixed 状态关闭某个工作项时,创建一个验证工作项。
保存团队区域操作
此操作用于定义什么用户角色可以修改某个团队区域。此时不存在前提条件。
保存项目区域操作
此操作用于定义什么用户角色允许修改某个项目区域。此时不存在前提条将。
取决于团队的流程,他们可能希望将某些存储库操作的访问权限限制到已分配了某些角色的特定团队成员。例如,某个人员可能分配了“错误筛选”角色。他们的职责是检查传入的错误报告,并在团队中分配这些错误。不应该允许其他团队成员做出此类分配。Jazz 使用流程权限来允许实现此类控制。
Team Process 支持流程区域中的角色定义。团队成员可以分配一个或多个角色。存在一个名为 default 的预定义角色。所有用户(包括不属于该团队成员的用户)都分配了 default 角色。在将团队成员添加到团队时,可以为他们分配附加的角色。
记得前提条件和后续操作在组件操作的上下文中工作。在上面的前提条件示例中,您了解到工作项保存和 SCM 交付是支持流程的操作示例。为了执行支持流程的操作,用户必须拥有适当的流程权限。操作及其关联的权限是针对特定的角色进行配置的。
权限是在操作所执行的具体操作级别授予的。例如,工作项保存操作执行诸如“modify / summary”和“modify / severity”等操作。对操作 ID 使用特殊关键字“any”的权限表示,指定的角色被授予在当前操作以及任何子操作级别执行所有操作的权限。例如,通过指定权限“modify / any”,可以将工作项保存操作配置为允许任何类型的修改。
向 default 角色授予执行顶级操作“any”的权限意味着操作可由任何人执行。相反,如果为特定角色配置了某个操作而没有授予任何显式权限,则会阻止该特定角色中的用户执行该操作。例如,通过允许所有用户创建工作项,但是将交付代码操作限制到负责代码的开发人员,从而允许所有用户编写错误报告,这可能是有意义的。为此,将以授予工作项保存操作的所有具体操作而不授予 SCM 交付操作的具体操作的方式配置 default 角色,并将定义和配置一个单独的开发人员角色,以授予执行 SCM 交付操作的所有具体操作的权限。
由于流程规范代表项目和团队的“交通规则”,只有在 Team Process 组件具有细粒度的权限结构,以便能够将流程定义限制为负责管理流程的团队成员时,流程规范才有意义。您可能不希望团队中的所有人都能够修改项目区域或团队区域。否则,有人可能会搅乱您精心设计的流程,从而可能导致严重的项目破坏。流程组件的保存项目区域和保存团队区域操作允许您定义此类限制。
下面是一些权限规范示例:
工作项保存权限 "any"
此示例允许任何人保存工作项。
SCM 交付权限
这里,开发人员允许向 Jazz SCM 交付内容,但是 default 用户则不允许。
请注意,Jazz 组件的流程权限支持目前还是一项正在进行的工作。因此,您可能发现有些支持流程的操作还不支持可配置的流程权限,或者还不支持您希望能够配置的级别的具体操作。
要更好地了解如何使用角色和权限,请参阅本文稍后的 将流程规范更改限制到项目和负责人角色 练习。
Jazz 还有另一个称为系统权限的权限结构。 其目的是定义粗粒度的存储库访问权限。存在三种可能的权限类型: reader 、 writer 和 admin 。 有些操作目前仅限于拥有 admin 权限的用户。例如,修改其他用户的权限设置和创建项目区域。
权限在用户编辑器中分配给用户,可以从项目区域和团队区域编辑器或从存储库连接的上下文菜单中打开该编辑器。还可以在 Web UI 的 Admin 页面上编辑权限。
参与者系统权限
Web UI admin 页面
可以使用 Jazz 属性 com.ibm.team.repository.enable.permission = true|false 来启用或禁用系统权限(请参阅 .../jazz/server 目录中的 teamserver.properties 文件)。
相反,流程权限提供了对支持流程的组件操作的细粒度控制。
可以在整个项目组织结构中非常精确和灵活地配置流程权限和行为。
每个团队可以自定义项目区域中指定的流程以满足团队的特定职责。如果将某个团队定义为另一个团队的子团队,则其还可以自定义其父团队的流程。例如,项目可能指定某些前提条件,在能够交付更改集之前,必须满足这些前提条件。 如果某个特定的团队希望为他们的更改设置更高的标准,则可以使用在将代码交付到流之前所必须满足的附加前提条件,对交付更改集的流程进行自定义。
团队可以一次自定义所有迭代的流程,或者可以定义仅在特定迭代期间应用的流程自定义。如果某个项目(或个别团队)具有某些不希望团队能够自定义的权限或行为,这可以通过将它们声明为 final 来实现。
流程模板在创建项目区域时进行选择。除了其他功能以外,它还为项目区域提供初始的流程规范和迭代结构。下面是 Jazz 现成提供的流程模板的列表。随着 Jazz 的发展,这些流程模板可能会有更改。
- Eclipse Way Process
- 该流程最初由 Eclipse 开发团队开发。“Eclipse Way“是一个基于迭代的非常敏捷的流程,集中于高质量软件的一致和按时交付。
- OpenUp Process
- OpenUp 流程是由 Eclipse Process Framework 项目 (EPF) 创建的流程之一。 包括该流程是为了提供一个有关如何集成现有流程的示例。
- Sample Process
- Sample 流程是描述 Cloudburst 参考项目特征的流程。有关详细信息,请参阅本文中的 Cloudburst 项目描述。
流程模板可以包括流程文档。您可以采用 HTML 形式将流程文档定义为文件存档。Eclipse Way Process 模板中提供了这样一个示例。如果使用此模板定义了项目区域,请打开该项目区域。在概述 页面上,单击 Process Description 部分下的 Eclipse Way Process 链接。这将打开一个浏览器窗口,其中显示了描述该流程的文档(该文档不完整,但是您可以了解大致情况)。
探索 eclipse way 流程
Eclipse way 流程文档
可以在流程模板的概述页面上指定文档存档。
流程文档存档
到目前为止,我们已抽象地讨论了项目区域、团队区域和流程权限及行为。为了使这些概念更具体,下面考虑一个名为 Cloudburst 的虚构项目,并将其项目和团队结构映射到我们已讨论过的概念。Cloudburst 项目结构非常简单,但是并非微不足道。它是代表性的已有项目,即必须支持现有客户群、具有正在进行维护的已交付产品版本和正在投入新产品开发的项目。它将是我们的参考项目。Jazz 包括的 Sample Process 模板是 Cloudburst 项目的规范。这就是在本文开头要求您使用此流程来创建项目区域的原因。
花几分钟时间检查一下下面的 Cloudburst 项目的摘要。请注意,该项目具有两个重要但是非常典型的项目分组:开发和维护,每个分组具有不同的开发里程碑和流程需求。开发中存在两个团队。一个团队从事客户端开发,另一个团队从事服务器开发。为方便本文的讨论,以及为了避免设法记住太多的姓名,因此仅有四个成员,并且每个成员通过参与多个团队,从而具有共同的职责。
项目: Cloudburst,一个负责新版本开发和现有版本维护的软件开发项目。版本 1 已交付,版本 2 正在开发中。
团队成员:
Kim:
项目负责人
Rick:
开发团队负责人
Carol:
维护团队负责人
Mike:
版本开发人员和维护开发人员
Zoe:
版本开发人员
开发线:
开发:
子团队:
服务器开发
成员:Rick、Zoe、Mike
客户端开发
成员:Rick、Zoe
迭代(发布版本):
发布版本 1、发布版本 2
迭代(里程碑)
m1、m2
迭代(里程碑阶段):
开发(可否决的流程)
终结(严格流程)
当前迭代:版本 2 / m1 / 开发
维护:
成员:Carol、Mike
迭代(发布版本):
1.01、1.02 (详尽流程、严格强制、很少例外)
迭代(里程碑):
1.01、1.02
迭代(里程碑阶段):
维护
准备交付
当前迭代:版本 1 / 1.0.1 / 准备交付
|
对于下面的讨论,您可能发现打开您使用 Jazz Sample Process 定义的项目区域是非常有用的。这将使您能够将讨论映射到 Cloudburst 项目的 Jazz 规范。
就流程和可交付件而言,该项目的主开发和维护方面差别相当大。每个方面处理具有不同计划的不同产品版本。因此,在项目区域的根中将它们表示为单独的开发线。这允许它们并行操作,并根据不同的开发和维护需求来自定义它们的流程。
主开发当前正在处理 版本 2。维护正在支持 版本 1。
版本 2 当前处于其第一个迭代 m1 中。此里程碑划分为两个名为 development 和 end game 的迭代,其中 end game 将需要更严格的流程,以便准备用于 alpha 测试的里程碑可交付件。维护具有两个里程碑 1.01 和 1.02,它们是仅维护的版本。这些版本需要具有非常高的质量。维护版本流程划分为两个迭代,从而将普通 维护 与紧跟在维护版本之间的 准备交付 周期区分开来。
此迭代结构在 Jazz 中的情况如何呢?
Cloudburst development 开发线
Cloudburst 项目区域:开发 开发线
Cloudburst maintenance 开发线
Cloudburst 项目区域:维护 开发线
检查您使用 Sample Process 定义的项目区域的概述 页面,您将在该概述的迭代概述 部分看到这些开发线。
Kim 是总体项目负责人,并且已经分配为项目区域的唯一成员,其他项目成员将在各自的团队中进行定义。
项目区域团队成员
支持此项目所必需的团队区域情况如何呢?检查项目定义,开发需要 开发 团队和两个子团队 服务器开发 和 客户端开发。Rick 和 Zoe 同时属于 两个团队。维护可以使用单个名为 维护 的团队来满足,其团队成员为 Carol 和 Mike。下面是此团队结构在 Team Organization 视图中的团队区域情况。
Cloudburst 团队结构
我们还没有描述用于完成所有这些工作的机制。我们将在稍后介绍这些内容。下面花点时间讨论一下如何在 Jazz 中指定流程。
Jazz 本身具有如下所示的详尽项目结构。可以看到,其 0.5 开发迭代由 11 个相似的里程碑(M1 至 RC2)组成。从 0.6 版开始,Jazz 创建了一个名为 0.6 的新迭代,并添加了用于维护的新开发线。
Jazz 开发迭代
在继续之前,让我们简单回顾一下。
- 项目区域定义团队、迭代和构成项目的可交付件。在创建项目区域时,您需要使用流程模板来指定流程。这为项目的流程奠定了基础。该流程应用于所有项目团队,但是团队可以自定义该流程以适合他们的需要。
- 项目区域必须至少包含一条开发线,开发线定义一组迭代。Cloudburst 项目具有两条开发线,以便管理当前版本维护和新版本开发的并行活动。
- 团队区域可以自定义与团队关联的构件的权限和行为。
- 团队区域和项目区域统称为流程区域。
- 可以为特定的迭代自定义流程。活动流程是当前迭代中定义的流程加上从父迭代和开发线继承的任何流程配置。 在 Cloudburst 示例中,主开发线的活动迭代指定为 。 在接近该里程碑结束时,当前迭代将更改为 版本 2 / m1 / 终结,并且该阶段中指定的更严格规则将变为活动的。
- 团队可以定义不同的角色,并且可以为每个角色配置不同的流程权限和行为。存在一个名为 default 的预定义全局角色,其适用于存储库中的所有用户。
- 操作权限定义给定的角色允许执行什么操作。
- 通过使用由 Jazz、您的组织或其他 Jazz 社区贡献者开发的前提条件和后续操作,您可以配置项目区域的行为。
流程权限和行为采用 XML 以声明方式配置,并在角色的上下文中指定。
对于 Cloudburst 项目,我们起初仅配置了 default 角色的流程,该角色适用于存储库中的所有用户。但是,您可以想象全都具有项目负责人角色的 Kim、Rick 和 Carol 可能被授予比其他用户更多的流程权限。在 团队流程自定义 部分,您将有机会将流程更改权限限制到项目负责人。
如果阅读了 Jazz 技术概述的团队流程部分和前面的流程操作、前提条件和后续操作讨论,您应该了解存在可以在流程中指定前提条件的不同上下文。您需要了解这些上下文是什么,以便确定可在给定的上下文中使用的前提条件。下面让我们研究一下这些上下文。
- 配置数据: 组件可以声明其具有影响自己行为的数据,此数据在项目区域中进行配置。配置数据在流程规范的 project-configuration 中指定,这意味着配置数据应用于整个项目,并且不能对其进行自定义。配置数据的示例是可用工作项类型及其优先级和严重性的集合。每个项目可以定义自己的工作项类型,然后该组工作项类型将对整个项目可用。
- 操作: 操作是组件允许流程通过确定权限、影响行为或同时通过这两种方式来对其施加影响的功能块。组件的操作一般集中于其存储库构件的操作。调用某个操作时,团队有机会在操作之前或之后插入适当的逻辑。例如,记得 Source Control 组件定义了一个代码交付操作。工作项组件的保存操作还邀请了流程的参与。存在两个可配置的行为方面:前提条件和后续操作。前提条件在执行操作 之前 运行,其目的是在允许修改存储库之前执行检查。前提条件支持可选地 可否决 的概念,稍后将对此进行详细描述。相反,后续操作在操作完成之后扩展操作,并潜在地对存储库做出附加更改。如果服务器端后续操作以某种方式失败,则整个操作都将被回滚。
- 事件: 组件可以产生事件以报告存储库中的更改。这些事件为控制流程提供了监视更改并在做出更改后采取适当措施的能力。可以定义对事件做出响应并执行自己的某些特定操作的后续操作。例如,在某个工作项状态更改时广播一个事件。通过为该事件配置后续操作,可以指定在某个工作项缺陷的状态变为 Resolve/Fixed 时,将创建一个验证工作项。
下面详细查看一个示例。您可以通过打开 Cloudburst 项目区域并转到 Process Specification 页面来按照本示例进行操作。
为项目指定的 配置数据 的一个示例是工作项优先级。
配置数据
下面是已经为 SCM 交付操作指定的前提条件的示例。 在即将把代码交付给团队之前,将检查此前提条件。此前提条件建议用户不要交付具有编译错误的代码,并在交付期间在 Team Advisor 视图中显示信息。
针对编译错误的示例前提条件
要在 Cloudburst 项目中定位此前提条件,您需要从 Team Organization 视图中打开 development 团队区域编辑器,并选择 Process Customization 选项卡。请注意,为该操作定义了多个前提条件。
请注意,此前提条件是为操作 ID com.ibm.team.scm.client.deliver 配置的。在其他操作中包括此前提条件没有意义。还值得注意的是 overrulable 属性,此属性适用于前提条件而不适用于后续操作。如果未指定此属性,则前提条件将缺省为不可否决的。所分配的值影响在 Team Advisor 视图中向用户显示的内容。对于您的团队,您可能希望将此值设置为 false,并自定义描述以解释将该前提条件配置为严格进行强制的原因。
当您交付具有编译错误的代码时,将会在 Team Advisor 视图中看到此问题的指示。
禁止编译错误
如果将前提条件配置为可否决,则会在详细信息窗格和上下文菜单中提供权宜之计,从而允许您请求忽略该前提条件。下面是该前提条件在 Team Advisor 视图中的情况。
交付否决
在请求否决前提条件以后,可以从 Team Advisor 视图的工具栏或上下文菜单中重试代码交付操作(请注意,如果从 Pending Changes 视图重试代码交付操作,则不会考虑您的否决请求)。
交付 - 重试。
然后代码交付操作将运行,由否决的前提条件检测到的任何问题将被忽略。请注意,您必须切换 Show Failures Only 工具栏操作才能看到成功的代码交付。
交付 - 否决完成
如果打开 Cloudburst 项目的 development 团队区域,您将看到里程碑 m1 的 end game 迭代已将前提条件的 overrulable 值重新定义为 false。这是因为该团队希望在该里程碑接近完成时更加谨慎。
我们提到了操作还可以具有后续操作;下面简单查看一下后续操作。记得后续操作与前提条件不同,后续操作成为操作的一部分。后续操作在组件操作已完成之后调用。如果后续操作的执行以某种方式失败,则操作将不会完成(更准确地说,操作将被回滚)。在创建项目区域时,存在一个流程可参与的初始化操作。这就是 Jazz Sample Process 创建 Cloudburst 参考项目的方式。下面是后续操作的一个示例。
示例后续操作
事件处理
是将要讨论的最后一个流程支持机制。Jazz 服务器可以产生事件以报告更改。流程规范或自定义可以声明对某个事件感兴趣,并指定一个或多个应该在发生该事件时调用的后续操作。当该事件发生时,后续操作接管控制,并执行为其设计的任何事情。工作项组件实现了一个针对工作项 stateChanged 事件的后续操作,此后续操作在工作项经历指定的状态转变时创建一个工作项验证任务。下面将此后续操作配置为每当某个缺陷转变为 Resolve/Fixed 状态时创建一个验证工作项。
工作项流程事件处理程序
此后续操作产生一个类似如下的新工作项:
验证工作项任务
Cloudburst 项目使用的 Sample Process 模板中没有定义这个特定的示例。
这些具体的示例应该让您大致了解了如何指定配置数据、前提条件和后续操作,以及在前提条件检测问题时用户界面中的一些响应。您将会非常高兴地发现,Jazz 在发现可用流程操作、事件、前提条件和后续操作方面提供了帮助。Jazz 还将在流程规范中插入用于这些内容的 XML 模板,因此您不必自己编写此 XML 的所有内容。我们将在 “团队流程自定义” 部分介绍这一点。
哎呀!我们已涉及了大量的话题。下面我们将介绍如何创建自己的自定义项目。
流程操作可以在服务器或客户端上实现,每种方法各有优点和缺点。在客户端执行的前提条件有时可以更加交互式、信息性并对用户非常有帮助,但是您不能确保自己是在保护服务器上的内容(如果这是您的意图的话)。其他具有服务器访问权限的应用程序(例如,Jazz Web UI)可能做出服务器内容更改,并搅乱您的意图。另一方面,在服务器上实现的流程顾问 (process advisor) 将是不太交互式的,但是可以保证将在服务器内容被更改之前运行。
Eclipse Way Process 模板提供了一个很好的例子。在该流程规范的初始化部分,存在两个后续操作;一个用于服务器,另一个用于客户端。下面是取自该 XML 的片段。
<initialization>
<client-initialization>
<followup-actions>
<followup-action
id="com.ibm.team.process.internal.client.runAssignedWorkitemsQuery"
....
</followup-actions>
</operation>
<server-initialization>
<followup-actions>
<followup-actions
id="com.ibm.team.process.internal.server.setUpProject"
....
|
在上面的示例中,存在一个客户端和服务器流程操作。Jazz 的约定是通过在 ID 中包括术语 client 和 server 作为限定符来区分客户端和服务器操作。
团队可以自定义其团队区域中的流程。团队区域编辑器在 概述 页面上有一个名为 Customize the process 的操作,当选择此操作时,将创建一个名为 Process Customization 的新编辑器页面,此页面允许团队自定义相对于其父级的流程。
团队区域概述页面
在团队区域中,通过创建 “团队自定义”,可以自定义流程以覆盖其父级所定义的流程的某些方面,自定义仅覆盖父流程的指定操作和事件,该自定义未提及的任何操作和事件将从父团队和项目区域继承其配置。自定义将完全取代(而不是扩展!)父流程中定义的操作或事件的已配置权限和行为。自定义语法与项目区域流程规范几乎完全相同。
终结流程
对于团队不希望行为或权限可进一步扩展的情况,操作和事件支持一个布尔 final 属性。如果未指定此属性,则其缺省值为 false;除非将其指定为 true,否则您一般不会看到 final 属性。如果设置为 true,则不能在项目结构的较低级别覆盖该操作或事件的权限或行为配置。例如,假设将某个父流程指定如下:
带有 final=false 设置的操作
有了这个终结值(这也是缺省值),子团队可以随意忽略编译错误前提条件。
如果父流程指定了
final="true",则自定义该操作的任何尝试都将被忽略。
记得 Cloudburst 项目的维护团队需要一个严格的流程来帮助确保高质量的修复。如果打开 maintenance 团队区域,您将看到所有源代码控制交付操作都具有 final="true" 属性。
正如您所知道的,Jazz 现成地包括一些示例流程模板,即 Eclipse Way Process、OpenUp Process 和 Sample Process。Team Process 组件支持通过使用一个简单向导来创建新模板。该向导产生包含单条开发线和一些嵌套迭代的模板,并打开 Process Template 编辑器。在此编辑器中,您可以指定自己的开发线、迭代、权限和流程行为,其过程非常类似于自定义现有的流程。
模板和实例化的项目区域之间的一个重要区别在于,模板的迭代结构没有持久化为存储库中的记录。对于模板,迭代是在单独的 XML 文档中定义的,如模板编辑器的 Iteration Structure 选项卡所示。还可以在模板的 Overview 选项卡上以图形化的方式编辑此 XML 文档。当在模板基础上创建项目区域时,迭代结构将转换为存储库中的持久对象。
模板在 Process Template Explorer 视图中进行管理,该视图在 Process 透视图中可见,并在存储库连接的 Administer 上下文菜单项下可用。下一部分 团队流程自定义将介绍如何创建和应用模板。
现在您已经大致了解流程是如何工作的,并具备了一些创建新项目区域的经验,下面让我们尝试执行一些基本的自定义。首先,您将对一个现有的项目区域做出一些更新。然后,您将创建一个简单的流程模板,并将其应用于一个新的项目区域。最后,您将处理流程权限和角色,本部分是作为教程来编写的。
让我们从使用 Sample Process 创建的项目区域开始,并做出一些基本的修改。如果希望遵照本练习进行操作,但是还没有使用该流程来创建项目区域,请马上这样做。要创建项目区域,将需要系统权限 repo.admin。如果您不是作为 ADMIN 用户(或者拥有 repo.admin 系统权限的用户)登录的,请马上这样做。
将做出的流程自定义如下:
可以从项目区域编辑器的概述页面更改当前迭代,如下所示。开发 线的当前迭代为 版本 2 / m1 / 开发。到达当前迭代的路径中的每个迭代装饰有一个亮蓝色箭头。要将当前迭代更改到 end game,可以选择该阶段,并使用工具栏操作 Set as Current。
项目区域编辑器,更改当前里程碑阶段
end game 迭代现已标记为亮蓝色,开发迭代已使用绿色勾号标记为“完成”。
迭代摘要,阶段更改完成
要使这些更改永久化,可以使用 Save 按钮保存编辑器。
此更改的结果在于,为 end game 阶段定义的流程(在项目区域编辑器的 Process Specification 选项卡中指定)现在变成了活动流程。
迭代开始和结束日期允许您使用 Jazz Agile Planning 组件来定义计划。这些日期是在项目区域的 概述 页面的 Process Iterations 部分定义的。选择任何迭代并单击 Edit Properties...,您将看到一个允许您设置开始和结束日期的对话框。
编辑迭代
下面创建一个简单的流程模板。这个流程模板是非常轻量级的,仅包含最少的必需内容。您可以对其进行扩充以适合自己的特定需要,然后,您可以将其部署到新的项目区域。
使用 Process 透视图中的 Process Template Explorer 视图,从存储库连接的上下文菜单中通过选择操作 New>Process Template 来启动模板向导。填写基本信息并单击 Finish。
流程模板向导
模板将出现在 Process Template Explorer 视图中,并且 Process Template Editor 将打开。
Process template explorer 视图
简单流程模板编辑器
(此图像已进行了等比例缩小)
起初,该模板中仅定义了一个简单的迭代层次结构。
下面继续添加附加的迭代。打开模板编辑器的 Iteration Structure 页面。将光标定位在编辑器中某个叶迭代的结束标记之后,按回车键,使用内容辅助功能(缺省为 Ctrl-Space 组合键)并选择 iteration 建议。瞧!您拥有了用于附加迭代的框架。
基本流程规范
返回到概述页面,并使用如下所示的上下文菜单将新的 milestone-phase 设置为当前 milestone-phase。
设置流程状态
此时,您可以保存流程模板,并且该流程模板将可供使用,但是您也许还希望做一件事情,即配置 save project area 和 save work item categories
项目操作的权限和工作项的配置数据。完成此任务的最简单方法是将 project-configuration 部分从诸如 Eclipse Way(在模板编辑器的 Process Specification 页面中)等现成模板之一中复制到您的流程模板的模板规范中紧跟在 team-configuration
元素之前的位置,然后对其进行修改以适合您的需要。作为提示,下面是取自 Outline 视图的 Eclipse Way 流程模板的配置数据摘要。
静态数据摘要
如果希望做更多的练习,您可以从其他模板复制感兴趣的内容,并且可以使用 “自定义现有的项目区域” 中描述的内容辅助功能,试着从头创建内容。
要使用此模板手动建立一个新项目,下面是基本的步骤。
- 在 Team Organization 视图中,使用此模板创建一个新的项目区域。
- 使用新的项目区域的上下文菜单创建一个新的团队区域。
- 使用团队区域编辑器添加或定义团队的成员。
- 可选地,自定义项目和团队区域的流程。
- 可选地,使用项目区域编辑器的 Work Item Categories 选项卡向项目区域添加工作项分类。
- 可选地,定义一个源代码控制交付流。
在本练习中,您将通过将流程更改权限限制到定义了项目负责人或团队负责人角色的用户,从而获得一些使用流程权限的经验。您将把此更改整合到使用 Sample Process 模板的新流程区域中,该模板是 Cloudburst 项目的基础。还可以将此更改直接放在模板中,但是由于这是一个学习练习,下面将在项目区域中做出更改。
记得 Kim 是 Cloudburst 项目的项目负责人。Kim 具有许多职责,其中之一是管理项目的流程。
作为项目负责人的 Kim
让我们从一个基于 Sample Process 模板的未受干扰的项目区域开始(不要使用在上面的练习 1 和 2 中使用过的同一个项目区域)。记住,创建项目区域需要系统权限 repo.admin。如果您不是作为拥有 admin 权限的用户登录的,请立即这样做。
从 Team Organization 视图中,使用 Sample Process 模板创建一个新的项目区域,并将其命名为 Cloudburst2。完成时,项目区域编辑器应该会打开。
Sample Process 模板定义了几个用户。在继续之前,让我们确保这些用户能够访问存储库(请参阅 侧栏:系统权限)。实现此目的方法之一是使用 URL:http://localhost:9080/jazz/web/projects/Cloudburst2 打开 Jazz Web UI,并作为用户 ADMIN (使用密码 ADMIN )登录。确保为用户 Carol、Kim、Mike、Rick 和 Zoe 设置了 repo.reader 和 repo.writer 权限。如果未设置这些权限,请立即设置,并单击 Update Permissions 按钮。
Web UI admin 页面
返回到 Jazz 桌面客户端,转到项目区域的 Process Specification 页面,并查找顶部附近的 saveProjectArea。saveProjectArea 操作当前是为 default 角色配置的。请重新为 projectlead 角色配置该操作。请注意,此操作的权限是在 project-configuration 部分中配置的。这是由于 saveProjectArea 操作在全局项目上下文中运行。也就是说,保存项目区域的权限并不依赖任何特定开发线的当前迭代,并且不能在任何团队区域中自定义这些权限。
向项目负责人重新分配角色
做出此更改之后,只有项目负责人 Kim 才能修改项目区域和创建根团队区域(如果选择值“any”并使用内容辅助功能 (Ctrl-space),您将看到此操作所执行的具体操作)。
通过注销,切换到用户 kim_cloudburst,然后重新登录,您可以验证这一点。作为用户 Kim,您应该能够修改和保存项目区域。如果注销并作为用户 rick_cloudburst(此用户不是项目负责人)登录,然后尝试保存项目区域,您将接收到不能执行此操作的通知。
保存项目区域被拒绝
到目前为止,您所能做的就是将项目区域修改权限限制到项目负责人。您还没有禁止任何人对团队区域做出流程更改。作为敏捷的团队,我们希望尽可能委托权限。这意味着我们应该允许团队负责人管理自己的流程(当然是在项目区域的范围内),因此下面将把团队区域更改权限限制到团队负责人角色。在 Cloudburst 项目中,Rick 是开发负责人,Carol 是维护负责人。development 和 maintenance 团队区域中定义了两个名为 development_teamlead 和 maintenance_teamlead 的特定团队负责人角色,如下所示。
开发团队区域. 角色
维护团队区域. 角色
要将更改权限限制到这些角色,您将使用另一个名为 Save Team Area 的流程操作。可以为此操作定义权限以控制谁可以做出流程更改。您将显式地为团队负责人角色授予对此操作的访问权限,但非常重要的是排除 default 角色对此操作的访问权限。
要为开发团队区域的团队负责人授予权限,可以做出以下更改:(但愿您现在已经很熟悉内容辅助功能了!)。
开发团队区域更新
请注意,我们为 development_teamlead 角色配置了 Save Team Area 操作,并授予了修改团队区域的权限。此外,我们为 default 角色配置了此操作,并通过不向其权限结构分配任何具体操作,从而拒绝此操作执行任何具体操作的权限。请注意,权限操作是在层次结构 teamarea->modify 中定义的(查看内容辅助功能对话框可以看到,还存在其他可用的操作)。
最后的说明。对某个操作可用的权限操作由提供该操作的组件所控制。组件可能没有定义任何特殊权限,在此情况下,该操作对所有用户可用。
Team Process 是一个深度嵌入的核心 Jazz 组件。此组件不定义流程,而是帮助您实施项目和团队所使用的流程。作为核心组件,它在您创建项目区域时就存在,项目区域是您的团队在 Jazz 中的所有活动的根。团队区域帮助您改进和组织项目并为其配备人员。所选择的流程可以在整个项目范围中定义,并根据各个团队的需要进行定制。Jazz 提供了一组流程模板和各种各样的流程扩展,以演示如何将流程嵌入日常的开发活动。这转换为在项目和团队中的一致执行。无论您的流程需求是适度还是广泛,Jazz Team Process 组件都能够帮助您执行所选择的流程。
团队流程开发人员指南 ——这个由 Process 组件维护的 wiki 主题解释了其他组件如何开放以实现流程支持,以及如何扩展诸如顾问和参与者等可用的流程构件集。
学习
- 本文中文版由 Jazz.net 授权发布。您可以通过免费注册成为 Jazz.net 的用户,查看本文的 英文原文。
- developerWorks 中国网站的 Jazz 技术平台概览:这里汇集了丰富的 Jazz 平台中文技术资源。 您可以通过这里了解更多关于 Jazz 平台和相关技术的信息。
-
Jazz 新手入门 为您全面介绍 Jazz 平台的技术概览,并提供相关的入门学习资源。从这里起步,了解 Jazz 平台,尝试全新的跨地域分布式协作开发方式。
- 查看最新的 Jazz 演示和多媒体,快速学习这一最新的软件交付协作技术,深入了解 Jazz 平台。
- 订阅 Jazz 相关文章和教程的 RSS 提要,随时获取最新的 Jazz 技术文章和教程。
- 订阅 Rational Team Concert 相关文章和教程的 RSS 提要,随时获取最新的 RTC 技术文章和教程。
- 访问 IBM developerWorks 中国网站 Rational 专区,获得关于 IBM Rational 软件交付平台(Rational Software Delivery Platform)产品的技术资源和最佳实践。
获得产品和技术
- 访问 Rational Team Concert 产品专题,了解 Rational Team Concert 产品家族的产品特性,并下载 RTC 的免费版和试用版。
- 下载 Rational Team Concert Express Edition (易捷版) 的免费试用版,体验面向部门级开发团队和中等规模开发团队的全新协作软件交付平台。
- 下载 Rational Team Concert Standard Edition (标准版) 的免费试用版,体验面向企业级和大型开发团队的全新协作软件交付平台。
- 下载免费版的 Rational Team Concert Express-C,需要 注册 Jazz.net 用户,并登录进行下载。
- 访问 IBM Rational 软件交付平台 V7 专题,了解 Rational V7 产品的方方面面。
- 获取免费的 Rational 软件工具包系列,了解最新的 IBM Rational 软件开发工具技术文档和资源。
- 下载免费的 IBM Rational 试用版软件,了解 IBM Rational 软件的最新特性。
- 获取更多 IBM 试用版软件,并熟练掌握来自 DB2®、Lotus®、Tivoli®,以及 WebSphere® 的开发工具和中间件产品,用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。
讨论
- 访问 Jazz.net 上的 Jazz 社区。并注册成为 Jazz.net 用户,您可以随时了解 Jazz 项目开发的最新进展,获取免费的 Jazz 平台软件及相关试用版软件下载。
- 访问 Jazz Space。在 developerWorks 这个专门为 Jazz 平台准备的 Space 里,您将发现更多关于 Jazz 的技术资源和信息,包括博客、产品演示、RSDC 讲座、Podcast、Webcast,以及 基于 Jazz 的商用产品试用版下载等资源。
- 查看 developerWorks
博客 并加入 My developerWorks 中文社区。
Jazz 是 IBM Rational 面向软件交付技术的下一代协作平台。Jazz 项目是一个开放的项目,它采用一种全新的开发模式——开放商业软件开发来开发其项目。Jazz 项目由 Jazz.net 负责维护。您可以通过 Jazz.net 了解更多关于该项目的信息。