使用 Rational Team Concert 创建多平台开发环境

技术狂人 · 发表于 2013-2-24 20:58:30

本帖最后由技术狂人于 2013-2-24 21:00 编辑

“企业现代化” 对大型机开发人员有何意义

取决于您的视角，企业现代化 可能具有不同的含义。如果您是软件开发人员，那么企业现代化有可能意味着使用现代技术实现解决方案，比如 Web 服务或源代码生成工具，或者一流的编程语言。如果您是软件架构师，那么企业现代化有可能关乎采用模型驱动的开发技术或采用面向服务的架构 (SOA)。这些视角考虑了企业现代化的技术层面。业务层面包括确保整个应用程序开发生命周期中的端到端可跟踪性，将开发活动与业务目标和优先级对应起来，从而通过 IT 实现来驱动业务价值。
所有这些视角都是符合逻辑的，而且依赖于我们所认为的企业现代化的核心：首要的是，要声明您真的在 “执行” 现代化，则必须先现代化您 “执行” 开发的方式。您需要确保您的多平台应用程序是由在整个项目生命周期中紧密协作的团队设计、开发和构建的。一般而言，在这一点上达成一致并不难，但想要这么做和实际这么做却是两回事。

首要的是，要声明您真的在 “执行” 现代化，则必须先现代化您 “执行” 开发的方式。

IBM® Rational Team Concert™（在非正式情况下常常称为 RTC）是作为一个多平台开发环境而开发的，支持大型机和分布式团队在整个软件开发生命周期中紧密协作。它提供了分布式开发团队使用了多年的功能，利用了实践证明在该环境中弥足珍贵的最佳实践和开发模式，还考虑了大型机环境的独特需求，该环境已经存在数十年，而且托管着如今仍在运营的基于大型机的应用程序。
现在，在您得出结论之前，我们的想法还不会让大型机开发人员使用分布式工具；这不会发挥作用，也不应作为目标。我们的想法是提供一个现代开发环境，使其拥有两个领域的优势，将在多平台应用程序上执行开发的团队联合起来，提供轻松且一致地进行协作的能力，还建立了在生产和维护高质量应用程序方面已取得成功的可重复模式。
您可能想知道这怎么可能实现开发环境现代化，毕竟分布式和大型机开发人员如今使用的工具和流程丰富多样。无可否认，这是一大挑战，但也具有巨大的回报。在本文中，我将提供开发用于多平台开发的 Rational Team Concert 结构设计的具体指南，重点介绍项目和团队区域的建立，以及组织软件应用程序和它们的开发的流程和组件。尽管这里列出的设计战略和考虑因素可能不适合所有环境，但可以将它们用作指南，使用它们为自己的项目团队开发初始 Rational Team Concert 设置。

多平台开发环境拓扑结构示例

在介绍 Rational Team Concert 结构的细节之前，让我们看看我们尝试完成的内容的概述。图 1 显示了我提出的 Rational Team Concert 中的一个用于多平台开发的软件项目的初始设置。

图 1. 用于 Rational Team Concert 多平台开发的初始拓扑结构

在这个简单的开发项目拓扑结构插图中，大型机和分布式开发人员几乎是并行工作的，在一个多平台软件项目中对软件工件进行更改。可在各种级别执行、构建和测试隔离的更改：

在开发人员级别 上，开发人员可向他们的私有存储库工作区提供自己的隔离更改，这个工作区由 Check-in 路径表示。开发人员可创建个人构建版本并执行单元测试。
在在团队级别 上，可将多个开发人员的更改提交到一个团队流（例如 Mainframe Dev 流）并向所有团队成员公开，由 Deliver 路径表示。此级别的构建版本可计划为在更改准备好集成测试时定期发生。
在项目级别 上，开发领导可接受来自各个团队的更改，将它们传输到 Integration 流中，确保集成的更改成功构建并为正式测试做好准备。3 ^6 z" ]: A' B9 O! U' i/ l

管理多平台构建请求

在这个多平台开发环境中，开发人员可发起自己的构建请求，团队领导可管理更加正式的构建版本和集成，最终提升到正式测试环境。所有这些都可以通过 Rational Team Concert 构建请求来无缝地完成，如图 2 所示。

图 2. 通过 Rational Team Concert 的构建请求流

基于哪些存储库工作区或流将保存要构建的源代码，Rational Team Concert 可以确定这些构建版本必须在何处执行，并处理代表请求者引起的构建请求的复杂性。通过这种方式，可以提供一种统一的、真正的多平台开发环境，该环境包含一个一致的接口，无论您是分布式开发人员还是大型机开发人员。
现在让我们看看总体概述中所示的每个元素的细节。

项目区域和团队区域

项目区域 是一个软件项目的 Rational Team Concert 表示。它定义项目交付结果、团队结构、流程和计划。项目区域在 Rational Team Concert 存储库中存储为一个顶级或根项。它引用项目工件并存储这些工件之间的关系。
项目区域的产品交付结果、流程和计划可能很简单，也可能很复杂。一个建立的项目可能拥有多条活动的开发线，比如：

一个或多个已发布版本的维护
一个新版本的开发
一个未来版本的实验性开发$ g3 G9 O: n2 {7 [+ J: E* B' Z

复杂的项目可能有一个团队区域 层次结构。通常会为每条开发线分配一个或多个团队区域。用户可能有多项任务需要它们在多个团队区域中执行。一些成员（比如项目领导）可能属于项目区域，而不属于任何特定的团队区域。对于多平台软件应用程序项目，通常可能（至少）有两个团队区域，一个用于大型机开发，一个用于分布式开发，不需要独立的团队区域。
对于简单或初始开发，项目可从一个项目区域入手，但不需要团队区域。随着项目复杂度增加，可以通过创建团队区域来使用逻辑边界（比如功能线、新版本、维护和实验性开发）隔离开发。当决定是在一个项目区域内创建一个团队区域来隔离开发活动，还是创建一个独立的项目区域来隔离开发活动时，一定要记住的是，团队区域可以继承父区域的流程和时间线，这个父区域可能是项目区域或一个父团队 区域。团队区域可自定义流程的各个方面，而且如果允许，还可以改写流程的所有或部分方面，或者它们也可以简单地继承父区域的特征。团队区域也可共享在项目区域中定义的通用组件。因此，如果目标是在一大群开发人员中组织一个项目结构，项目或团队区域层次结构很有用。
项目流程（您用于组织和控制工作流的实践、规则和指南集合）是在一个项目区域中定义的，可在团队区域、时间线和迭代中进一步定制流程。当一个流程中的不同组需要使用不同流程时，有必要使用团队区域。

项目和团队区域设计战略

每个主要的软件项目都可以有一个或多个 Rational Team Concert 项目区域。这使计划项目范围、衡量风险和管理资源和交付结果变得更简单。一些客户将一个软件项目视为一个应用程序或一组应用程序，比如在线零售或应收款；其他客户可能将软件项目视为组织中的一个职能区域，比如零售或薪资部门。在任何情况下，都应该将软件项目视为一组正在开发的功能。探索如何在您的组织中执行此类开发会帮助您开发项目和团队区域设计战略，提供一个良好的起点。例如，考虑回答以下问题：

目前如何在组织中完成开发？
开发工作的逻辑划分是怎样的？
是否有跨不同软件项目执行活动的开发资源？或者在同一个项目中，但跨不同应用程序区域的开发资源？
“开发活动口袋” 是什么样的？
如何管理版本？
如何将交付结果引入生产中？3 Y; P8 X4 l) b7 Y# G

接下来，定义与功能区域对应的项目区域，将这些区域分解为与给定功能区域内的应用程序对应的团队区域。完成这项工作后，可以继续定义 Rational Team Concert 环境的其他结构元素，包括组件、流、工作区和系统定义。请记住项目区域和团队区域的以下特征：

每个项目区域包含一组跨团队区域使用的软件工件或通用组件，比如 copybook。
每个项目区域将拥有它自己的用于每个版本的一组开发流，包括一个生产流，以管理各个开发阶段中的应用程序工件。
项目区域可使用来自主要 Rational Team Concert System Definitions 项目区域的系统定义，创建重写项目或特定于该项目的其他定义。
每个团队区域将拥有并管理一组针对软件项目中某个特定应用程序的组件。
每个团队区域将拥有自己的开发流。
团队区域能够以只读方式访问其他团队区域中的组件。
$ m5 ~2 r: O( Z3 a& r2 }4 d

流和组件

流是一个包含一个或多个组件的集合。组件是一组在变更控制下维护的相关工件，比如一个插件的代码或在一个网站上使用的一组文档，或者一组可编译来构建交付结果的源代码工件。源控制下的工件分组到组件中，组件可包含在 0 个或多个流中。
第三个元素是存储库工作区，您可以在这个区域中查看或修改工件。开发更改是在一个存储库工作区中进行的，然后传输到一个流。工作区包含该流的一个或多个组件。来自存储库工作区的工件可加载到客户端机器上的本地（基于 Eclipse）工作区中，它们可在这里进行修改。存储库工作区一般为开发和构建用途而创建。

流设计战略

Rational Team Concert 流结构是管理整个变更周期的基础。尽管最终定义的流结构取决于您自己站点的独特需求，但我们提出了一种基本的流结构，可以将该流程用作任何多平台项目的起点。在这个示例中，我们有一个 BankDemo 多平台应用程序，它有一个表示为 Bank Dev 的大型机功能和一个表示为 Web Services Dev 的分布式功能。从开发到集成流的变更流程由 Rational Team Concert 管理并使用箭头标明。到正式测试和生产流的变更流程由 Rational Team Concert 提升操作发起，并经过封装和部署，所以不存在箭头。
图 3 演示了一个建议的初始流结构。

图 3. 用于多平台开发的建议的初始流结构

组件设计战略

组件的概念在 IBM® System z® 上的几乎所有源代码管理系统上都是一致的，例如：

Serena ChangeMan 要求您基于应用程序结构来定义工件。
CA Alchemist 有 5 个管理字段，建议您使用前两个字段来在逻辑上组织应用程序。
CA Endevor 建议您将工件分组到一个系统和子系统结构中，以便按逻辑方式组织它们。
0 h! x. V; C( O& X& d) f

在 Rational Team Concert 中，组件可帮助您控制访问，管理和合并更改和构建版本，并实现协作式开发。您可将大型应用程序拆分为多个较小的组件，在流和工作区之间重用代码，使构建一个系统的子集变得更简单。组件由 Eclipse 项目（对于基于大型机的工件，为 zComponent 项目）组成。这些项目包含在执行构建时使用的工件和构建版本元数据。在创建组件时，您可以将相关的工件放在一起（例如，一起构建或构成一个子系统的组件）。对于具体的平台，没有必要按源代码语言或技术来分离组件。我们的建议是基于团队结构、访问需求和构建需求，将源代码和其他工件分离到组件中。
要开发组件战略，请执行以下基本步骤：

将软件项目（项目区域）分解为应用程序（团队区域）。这个流程已在前面的 Rational Team Concert 项目和团队区域战略一节中介绍过。
识别应用程序中和之间通用的共享源代码。这样，您就可以将一个项目区域通用组件和团队区域通用组件用于每个团队区域。
将每个应用程序分解为逻辑开发区域。这样，您的每个团队区域就会有一个或多个团队区域组件，当然还包括前面介绍的每个团队区域的通用组件和项目区域。
/ C, V! k# B& ~/ H

开发组件战略时，需要注意诸多考虑因素：

作为一条指导原则，组件内容不得超过 500 个源文件。这不是一种产品限制，而是一种实现协作式开发和构建活动的最佳实践。如果客户端拥有很少更改的源代码，这些源代码可能包含在一个组件中，您可能打破了 500 个源文件的限制。此外，即使一些组件稍微大一些，也没什么问题。
可能无法检测一些源文件的应用程序所有权。在这种情况下，自动化分析可能很有用。
开发人员可按组件加载源代码，所以一定要将源文件逻辑地分组到组件中，使开发人员无需加载整个流即可工作。
可能有一些控件限制了哪些开发人员或团队可以更新源代码。组件可以控制访问，所以在设计组件战略时请考虑访问控制。
组件名称应尽可能短，同时仍然能传达含义。
组件名称必须在一个项目区域的上下文中是惟一的。
- P8 d- F1 E- t0 o" y/ V

结束语

总体来讲，没有为多平台应用程序开发设置 Rational Team Concert 的正确方式，但在您开始设计 Rational Team Concert 环境时，有多种最佳实践为您提供了最初的指南。一般而言，您将为软件项目定义包含团队区域的项目区域，而这些团队区域表示您项目中的功能区域。您可以将软件应用程序组织为流，这些流表现了应用程序内容在生命周期的各个阶段中的具体状态。您仍然需要考虑如何将这些应用程序分解为组件，以实现团队协作，同时最大程度地减少每个开发人员可能需要处理的源代码量。组件化还考虑了限制对应用程序的某些区域的访问的需求。
通过考虑开发团队将如何使用 RTC 开发和维护度平台应用程序，以及如何应用该知识设计您的项目、团队、源代码流和组件的结构，您就会拥有一个现代化的、多平台的开发环境的基础，在该环境中，团队成员可以在功能区域内和跨功能区域协作，通过统一的接口实现更改、执行单元测试和解决调试问题。

技术狂人 · 发表于 2013-2-24 21:01:05

原文地址：http://www.ibm.com/developerwork ... -concert/index.html

帐号		自动登录	找回密码
密码			立即注册

[推荐] 使用 Rational Team Concert 创建多平台开发环境

本帖子中包含更多资源

相关帖子

SCMLife推荐 /1