【IT168 技术】概述

　　IBM RTC 是一个软件协作交付环境，它包含了计划制定及管理，工作项集成管理，代码版本控制管理，以及构建管理等诸多功能，这些功能使得Jazz环境的协作能力非常强大。在RTC中，用户可以通过工作项对工作内容进行信息更新和任务分配，借助工作项和人员之间的联系方便地进行信息的交流和展示，并可以从不同的层面和角度了解整个Team的工作进行情况。

　　这份文档描述了RTC应用于软件开发活动的通用模式，并介绍了推荐的流程以及使用RTC进行日常开发活动的策略。希望通过本文向软件开发团队介绍一种可靠的流程和工具环境，来支持项目的软件开发需求。在软件开发活动中应用RTC能够使得管理和平衡项目成员工作变得更为简单和清晰，并且可以在项目组内部进行有效的沟通，提高生产合作效率。

　　内容安排

　　本文内容的结构如下：在第一章将介绍RTC中的相关定义，让用户熟悉RTC使用中的一些常用概念。在第二章中将介绍软件开发团队在开始使用RTC时，如何对RTC项目进行基础设置以适应团队需求。第三章将介绍RTC应用于具体软件开发活动时的使用方式，重点介绍如何使用RTC进行项目管理和代码管理/版本控制。最后是对本篇文章的总结。

　　1. 定义：

　　RTC：Rational Team Concert

　　SCM：Source Code Management源代码管理

　　Local Workspace： 本地工作空间，它是一个与存储空间关联的客户文件系统，用户可以在这个系统中处理component的工作。这个工作空间可以独立地在本地存在，也可以连上服务器，进行更新的上传或者下载。

　　Repository Workspace： 服务器端的个人存储空间，它可以视作Stream的一个镜像，并可以与本地工作空间相关联，处理来自于本地工作空间的变更或者接受来自于Stream的变更。

　　Stream：类似于branch，或者release，是一个存储对象，它包含一个或多个component，并且与另外的Stream版本独立。Stream会追踪版本变化的历史记录。

　　Component： Component 是一个组件的集合，例如一个Eclipse的插件，或者一组描述网页设计的文档。 Component的owner是project area，而且只有project area的成员才能够访问具备版本控制的component中的代码。

　　Compartment：基本的控制列表。在RTC中，对应Project Area。应控制使最少人数的成员可以访问compartment，并且有准入业务流程控制。

　　Change Set： 变更集，一个存储对象，是某次开发活动后发生变更的文件集合，通常与一个工作项相关联。

　　Pending Changes：待处理的变更。当local workspace，repository workspace和stream之间由于发生变更导致出现不一致的情况时，需要用户决定处理方式的情况。这些待处理的变更将会被列在pending changes视图中，等待用户的操作决定，例如接受，交付，或者是处理冲突。

　　Baseline：基线，记录某个特定时间点的单个component内的配置项状况。

　　Snapshot：快照，记录某个特定时间点的多个component内的配置情况，可以覆盖一个或者多个stream。

　　Checkin：这个操作可以将变更集由本地工作空间上传至服务器端的个人工作空间

　　Accept: 这个操作可以将服务器端的变更集和baseline接收到个人工作空间

　　Deliver：这个操作可以将变更交付至stream

　　Load： 这个操作可以将变更集从Stream或者其它工作空间下载至本地工作空间

　　Build Definition：构建定义，可以定义build的时间间隔，哪些build脚本被调用，以及build从哪些工作空间中取得文件。

　　WorkItem：用于描述工作的细节和状态，有多种类型和层次，例如从最大的类型到小的类型有Epic，Story，Task以及Defect， Blocker等其他类型，并且可以由用户自定义新的WorkItem类型。

　　RTC项目的基础设置

　　当软件开发团队开始使用一个刚创建的RTC项目来支持软件开发活动时，需要对该RTC项目作一些基础设置，以使RTC项目适应团队需要，下面就对这些基础设置作简要的说明：

　　2.1 角色设置 (Role Configuration)

　　角色定义了一个团队中成员的不同职责，并决定了团队成员在RTC项目区域中所具有的的权限。

　　每个项目区域(Project Area)和每个团队区域(Team Area)都有角色的设置。这两层的角色权限设置是相互独立的。可以通过两层的角色权限设置实现复杂的权限控制。

　　以Scrum模板为例，该模板提供了如下几种预定义的角色，项目管理员可以根据需要添加自定义的角色。

　　▲图1.RTC的角色设置

　　2.2 项目设置 (Project Configuration)

　　通过对项目权限的设置，使得不同角色拥有不同水平的权限，规定了角色可以做和禁止的操作，对角色功能做了很好的区分

▲　图2.RTC的项目权限设置(角色权限矩阵图)

　　2.3 团队设置 (Team Configuration)

　　在团队区域内部可以对角色权限作更进一步的设置，其设置方法和项目设置类似，也是针对不同角色赋予操作权限。

▲　　图3.RTC的团队权限设置(角色权限矩阵图)

　　2.4 访问控制 (Access Control)

　　出于对项目安全方面的考虑，RTC项目提供了对项目的访问控制，可以限制仅有本项目成员可以访问项目区域，或者设定访问名单，允许访问名单中的人员访问项目。

▲图4.RTC的访问控制

　　2.5 前置条件设置 (Preconditions Configuration)

　　在项目中，可以对某些操作的前置条件(Preconditions)或者跟进操作(Follow-up actions)进行设置：

　　例如，我们可以设置所有人在执行Deliver操作之前，必须要有相关的工作项和注释。这样可以使每次的Deliver都有确切的根据和记录。

▲图5.RTC的操作前置条件设置

　　2.6 时间线设置 (Timeline Configuration)

　　可以通过时间线设置明确团队的开发进度，规划开发周期。

▲　　图6.RTC项目的时间线设置

　　2.7 工作项分类设置 (Work Item Categories Configuration)

　　可以在Project的Work Item Categories标签中进行Categories的设置，工作项分类是树形结构的，用户可以自己定义这个树形结构的每个分支和节点。在创建工作项时，用户就可以在File Against属性中选择已设置的分类

▲图7.RTC的工作项分类设置

　　小结：

　　RTC项目的基础设置到这里告一段落，完成这些基础设置之后，团队就可以开始借助RTC开始工作了。事实上，RTC还支持工作项和流程定制的功能，但是限于篇幅，本文不对这方面作深入探讨。

　　3. 在软件开发活动中使用RTC

　　3.1 使用RTC进行项目管理

　　RTC具有计划制定和管理以及强大的工作项管理的功能，可以很好的实现项目管理支持。下面介绍RTC在项目管理方面的应用。

　　3.1.1 用Product Backlog管理产品需求

　　RTC的Product Backlog是一种特殊类型的Plan，可以将它视作一个需求池，它在产品开发的初期生成，以列表形式描述用户的需求，作为产品的待办事项，并在开发过程中不断更新完善。由Product owner负责管理。

▲　图8.一个Product Backlog的示例

　　3.1.2 制定项目计划

　　项目经理可以根据时间线划分，制定Release Level和Iteration Level的开发计划。开发计划可以明确该阶段的工作目标。可以从Backlog中将需求拖拽到Plan中，作为这一阶段的开发目标。项目成员可以方便的在Plan视图下查看该阶段的工作项状态。

▲　图9.RTC提供的Sample项目中的Plan视图

　　3.1.3 利用工作项管理开发任务

　　工作项用来描述某一项具体任务，根据粒度的不同，可以划分为Epic，Story，Task这些不同层级的工作项。Epic是位于顶层的工作项，它描述某个大的方面的工作。Story则描述一个具体的事务性的可追踪工作，Task则细化到daily的工作任务，可以直接由完成与否来衡量。工作项的owner确保工作项的执行，可以添加工作项的subscriber，使得工作项有任何的状态更新都会通知subscriber列表中的项目成员。各个工作项可以建立联系，例如父子关系，验证关系等等，通过这些关联关系，我们能从整体上把握目前的工作状态以及工作之间的依赖关系，从而更好地发现对工作进度造成影响的问题并有效解决问题。

▲图10.RTC中不同level的工作项

　　项目成员可以方便的通过建立查询，通过各种条件组合查找到符合条件的工作项。这些查询可以保存在查询预定义列表中以备随时使用。

▲图11.通过建立查询查找符合条件的工作项

　　3.2 使用RTC进行源代码管理和版本控制

　　RTC另一项强大的功能就是支持源代码管理和版本控制，可以支持多人团队共同开发，能够确保更新被所有开发成员及时得知，并且可以预先侦测到潜在的代码冲突。

　　我们从以下几个方面来介绍RTC的代码管理和版本控制功能。首先当我们要使用RTC管理Source Code时候，应明确如何将Source Code划分为不同的Component存放，并根据具体的开发，测试，构建需求划分Stream。在开发人员进行开发活动，并将自己的对当前代码的变更上传至服务器时，需要理解RTC进行代码变更的工作模式并正确操作。3.2.2节介绍了RTC代码管理的三重工作空间模式，3.2.3节则介绍了如何理解视图中变更集的标记意义并执行相应的操作。在这一小节最后将介绍RTC强大的代码历史记录功能：基线和快照，可以方便地对代码历史进行追溯和恢复。

　　3.2.1 Stream 和 Component划分的策略

　　Stream可以视作某个版本的代码集合，一般情况下，我们要为当前release建立一个主开发Stream。我们可以借助RTC的快照和Flow Target功能方便的复制一个stream的当前状态成为另一个Stream，使其成为主开发team的一个分支。出于对构建(Build)的需求，我们还可以建立一个集成stream，用来将开发stream中的内容作一些整合，用来进行构建。

　　Component是某一个功能模块的代码集合，可以根据功能模块对代码进行component划分。例如名为Install的Component包含了安装模块，名为Interface的component包含了界面设计模块等等。来自第三方的open source code以及核心的Jewel Code应该分别单独用Component存放，以确保代码来源清晰并且受到保护。可以为Component指定Owner(Owner可以是个人，团队或者整个项目区域)，严格控制Component内容的读写权限。

　　当代码按我们划分好的stream和component存放于RTC的工作空间时，我们就可以在RTC的代码管理和版本控制功能支持下进行协作式的代码开发活动了。下面将介绍RTC代码管理的三重工作空间模式。

　　3.2.2 三重工作空间的工作模式

　　RTC的代码存在于三重相互关联的工作空间，如图所示：

▲图12.RTC的三重工作空间(Source Code Management)

　　Stream：位于server端，是代码的交付目标，对具有权限的开发人员可见

　　Repository Workspace：位于server端，可以视作stream的个人镜像

　　Local Workspace：本地工作空间，位于本地，与server端的Repository相关联

　　开发人员无论是接受来自stream的变更还是向Stream交付本地发生的变更，都要通过中间层Repository Workspace，这样做的好处是当开发人员修改了同一个文件时，可以在Repository Workspace提前发现冲突，避免都向Stream中提交变更时产生严重的冲突造成变更丢失或者代码混乱。

　　开发人员的开发活动主要位于本地的工作空间，当有其他开发人员向Stream交付了新的变更，这个变更将显示在个人的Repository Workspace 中，由开发人员自己决定是否接受这些变更，并下载到本地。

　　当开发人员在本地工作空间进行软件开发活动，使得本地的workspace发生了变更，可以进行check-in操作向Repository Workspace check in发生的变更。再由Repository Workspace向Stream进行deliver操作完成变更的最终交付。

　　以下步骤图描述了RTC中的版本控制流程

　　步骤1：

　　Developer 甲： Local 修改 -> Check-In -> Deliver to Stream

　　步骤2：

　　Developer 乙：Accept(Developer 甲的修改)from Steam-> Load 到 Local

▲图13.RTC的版本控制流程

　　3.2.3 与Stream之间进行变更的交互更新

　　下图显示了pending changes中不同状态的变更集：

▲图14.Pending Changes中变更集的不同状态

　　? Unresolved 是可以 Check-In 的变更集

　　当用户在 Local 更改了代码文件时，就会出现 Unresolved 目录，里面列出了所有的更改文件。开发者可以将更改过的文件，分成几个不同的 Chang-Set 来 Check-In。

　　所有 Unresolved 的变更可以通过 Undo 来随时撤销。

▲图15. Unresolved状态的变更集可执行Ceck-in操作

　　? Outgoing 是可以 Deliver 的变更集

　　当成功 Check-In 后，会在 Outgoing 目录中出现等待 Deliver 的变更集。

　　对于还未 Deliver 的 Change-Set，开发者可以随时再次修改，再次做 Check-In。

　　如果用户想把这次 Check-In 的东西固定下来，再次修改的变更作为一个新的 Change-Set 的话。如图15可以把已经 Check-In 的 Change-Set 标记为 Complete。就可以再次 Check-In 新的变更，而又不会影响到上次作的变更，会在 Outgoing 中出现 2 个针对同一文件的不同的 Chang-Set。这也正是 RTC 对于 Chang-Set 概念的优势体现。

▲图16.针对同一文件通过Complete操作chek-in两次变更

　　当准备做 Deliver 的 Change-Set 与其他开发者的 Change-Set 有冲突时，RTC 中会显示一个双向箭头标记，如图16，这时候可以做 Discard 自己的 Change-Set 或者作 Merge。

▲图17.处于冲突状态的change-Set

　　? Incoming是可以 Accept 的变更集

　　如果Local 已经 Load 过关于这个变更集的 Component，当开发者 Accept 一个变更集时，会自动 Load 到开发者本地的环境中去。如图显示为 loaded。

　　如果Local 没有 Load 过关于这个变更集的 Component，那么 Accept 将只是在服务器端操作。

　　3.2.4 基线和快照功能

　　在repository space中右键选择某一个component，可以创建baseline，baseline将会记录component内文件的当前状态，并可以在任何情况下方便的恢复到该baseline的状态。

▲图18.新建Baseline操作

　　右键选择stream或者repository space，则可以对整个stream或者repository进行创建snapshot操作。

▲图19.新建Snapshot操作

　　Snapshot将会记录整个stream或者repository space的当前状态。

　　而在Snapshots视图中，可以选择曾经创建的snapshot，方便地进行Stream或者repository space的重现工作。

▲图20. 从Snapshot恢复Stream或Repository Wworkspace

　　RTC以其特有的三重工作空间模式和可视化的交付/接受变更视图，实现了完备的代码管理和版本控制功能，并能够有效避免可能产生的冲突。其强大快速的baseline和snapshot功能，又为代码安全可追溯和可恢复提供了保障。

　　3.3 构建管理 (Build Management)

　　RTC还提供了Build管理的功能。通过创建构建定义(Build Definition)和构建引擎(Build Engine)，RTC能够发起对指定Stream的Build请求，并且调用脚本实现build过程。RTC还提供了与Rational BuildForge 工具的集成，可以借助BuildForge在自动化Build方面的强大功能完成代码的Build工作。

▲图21.新建Build Definition操作

▲图22.新建Build Engines操作

　　小结：

　　本章介绍了RTC应用于软件开发活动中的一般模式，着重介绍了开发人员使用RTC进行代码版本控制的流程。同时也对RTC用于项目管理和构建管理作了简略介绍。

　　总结

　　RTC作为新一代的软件交付协作环境，为软件开发团队提供了从需求到计划，从开发到最终交付的完整平台。它提供的功能丰富而灵活，一个团队如果能够熟练运用RTC进行软件开发活动的支持管理，必将大大提高生产效率，减少管理和沟通协作的成本，它强大的代码管理和版本控制功能也为软件开发团队很好地解决了协作开发中繁琐而复杂的问题。本文将RTC应用于软件开发活动的一些经验进行分享，为软件开发团队提供一定的借鉴，希望RTC这个强大的工具能够更好地支持软件开发团队的工作，交付更多更好的产品。