2267人阅读
接着上次会议
后。继续宣讲RTC。
所以提前做些预习工作
稍微search 发现IBM的RTC的东西都帮你整理好了。BM 官方RTC学习路线图都出来了。
所以说。根本上不用自己劳心找资料了。
第一部分：
要注册个jazz。net的账号。
有点变态的是：Password must have a minimum of 3 alphabetic characters
（这是我第一次看到这么变态的密码规则。目前未知IBM为什么要这么做。****e123*56）
入门中文文章：
Rational Team Concert 是 Jazz 平台的基于 Eclipse RCP 的客户端，是一个为软件开发团队创造协同工作环境的软件。
Rational Team Concert 除了小组联合 Jazz 环境中的性能之外，还包括整合的工作项目跟踪，
源代码控制和构建管理支持。它将为敏捷小组提供开发环境中高度协作的经验， 尤其是对那些小型和中等规模的团队。
RTC的5个功能
：包括大部分ClearCase的功能，继承改进了UCM。（使用过UCM的人会很容易上手）
：包括大部分ClearQuest的功能，并且糅合了ALM package的思想.(
ClearQuest
的人会很容易上手,不过阉割版的。比
ClearQuest会差很多。别期望太高
：自动构建功能，类似
功能。（具体不清楚它的power程度，待观察）
：项目管理功能，敏捷的项目管理。其实就是一些数据的统一展示。和简单的时间划分。（具体不清楚它的power程度，待观察）
：报表，仪表盘等功能.(IBM一直鼓吹的
报表。具体没用过。不知道power程度，待观察)
未来3.0版本会加入
：需求管理功能，从Doors那边继承过来的。
：测试管理功能，从RQM那边继承过来的。
其实就是ALM+UCM+Jazz三大概念的融合。
ALM的研究见地址：
。ALM本身不是个新的概念，只是IBM这次的ALM有点较新。因为重新包装过。
UCM的研究见地址：
。UCM是个还算复杂的概念。值得试验体会。
Jazz的研究见地址：
，Jazz我也不是特别深入理解。皮毛而已
RTC这个产品得天独厚的糅合了自己家的精兵强将的绝技。不知道能够成为武林高手不。还待观察。
几个基本概念为：（IBM的一个新产品就会附带很多新概念。要习惯。
1．Repository
：用来存储 Jazz 的相关数据，每项数据有一个唯一的 ID 所标识。Repository 组件的 API 提供了创建，更新，追踪和删除数据项的功能。
Repository 由关系数据库来支持，目前 Jazz 支持两种关系数据库系统，分别是 Apache Derby 和 IBM DB2 数据库
（这个比较悲剧）
收到消息说可以支持oracle等数据库了。。（不过只有企业版支持大部分数据库。还好有60天的全功能试用期。其他版本基本上脑残
查证官方资料：
IBM& Rational& Team Concert 标准版支持Oracle 10g R2，DB2 9.1/9.5。
IBM& Rational& Team Concert 易捷版支持Apache Derby。
IBM& Rational& Team Concert Express-C免费版支持Apache Derby
IBM& Rational& Team Concert Enterprise企业版支持 Apache Derby IBM DB2 Microsoft SQL Oracle
2．项目域 (Project Area)
：项目域是项目在系统中的表示，提供了对项目流程，进度安排，团队架构等的定义。总之，项目域可以管理项目相关的方方面面和项目各要素之间的联系，范围涵盖项目的开发和维护。
3．团队域 (Team Area)
：团队域是团队在系统中的表示，提供了对团队成员，成员的角色，权限，团队所要完成的开发任务，团队基于项目流程的定制等方面的定义。一个项目域可以包含有一个或多个团队域。
4．工作项 (Work Item)
：工作项是对用户要完成工作的描述，涉及项目不同的模块或功能工作项可以被集合在 Work Item Caretory 里面，便于查看。
Work item 有不同的类型，可以是一个需求变更，一项开发任务，一个需要解决的缺陷或者是任何一种自定义的工作。开发人员的信息交流和协作就围绕 work item 展开。
5．流程 (Process)
：流程在项目域中定义，不同团队可以根据自身情况在团队域中进行定制。流程可以根据项目复杂度，规模的不同而不同。与流程相关的还有两个比较重要的概念 :：
(1)流程模板 (Process Template)
：不同的流程模版提供了不同侧重的对流程的详细说明以及迭代结构的描述，用户可以在流程模版的基础上稍作修改以得到适合自身项目的流程定义。
(2)流程行为 (Process Behavior)
：不同的流程，有对操作的先决条件及后续操作的不同定义，流程行为用来定义流程中操作的先决条件及可能的后续操作。
&活动：定义工作细分以及工作流
能力模式：描述一组可复用的活动
交付流程：描述用于执行特定项目类型的完整和集成的方法，例如迭代流程或瀑布式交付流程
描述符：描述活动中的具体内容元素如任务，角色和工作产品
Jazz 平台提有两种预先定义好的流程
可供使用，另外用户也可以根据项目特点自行修改或者创建流程。
Jazz 提供两种流程模板，分别是 Eclipse Way 和 openUP
，Eclipse Way 流程是一套适用于敏捷开发的迭代式流程， openUP 流程则保留了 Rational Unified Process(RUP) 中的很多元素，
6．开发基线 (Development
：代表项目域中一组独立的开发活动，这些开发活动有自己的目标，可交付程序，团队，流程，进度安排等。比如一个项目域中包含对某项目新版本的开
发以及旧版本的支持和维护，就可以定义两条开发基线，一条描述新版本的开发，一条描述对旧版本的支持和维护。
7．迭代 (Iteration)
：项目开发由不同的开发周期组成，迭代定义了不同开发基线下不同的开发周期。
8．角色和权限 (Roles and Permissions)
：在项目域和团队域中都可以对角色进行定义，一个团队成员可以被分配一个或多个角色。权限主要定义了用户所能够执行的操作，不同的权限，可执行的操作也不同。
如何使用 Rational Team Concert 开始软件开发的工作，
包含以下几个步骤：
1. 创建 Repository 连接
&2. 构建项目
连接到 Repository 后，可以创建项目域，项目域主要被用来管理项目的发布，团队的结构，项目流程和进度安排等。
（ps：想知道自定义流程在哪里？
从ClearQuest那边继承过来状态矩阵图思想，可以定制流程。
&& 3. 构建团队
创建项目后，可以创建团队域，部署团队人员，分配团队成员在项目流程中的角色，定义团队在完成项目的过程中所需要的信息。
（ps：想知道创建团队域为什么要关联一个开发基线？
从ClearCase那边继承过来UCM思想。什么隐含基线之类都有。这样想就明白了。
创建用户的时候，可以上传个相片。比较神奇。。。哈哈。
全部用户，这样确实非常好找。一目了然。并且团队之间都好认识。（如果使用真实相片的话）
&& 4. 为团队配置项目流程
创建项目后，可以根据自身项目的特点对项目流程进行配置，项目流程一般由开发基线 (Development Line)，迭代
(Iteration)，项目角色及工件类型组成。
在 Rational Team Concert
中用户可以修改或创建开发基线及迭代以完成对项目流程的配置，通过修改迭代的起止时间来安排项目的进程。
通过对 Process Specification 的编辑，用户可以从多个方面对项目流程进行创建，修改，定制自己的流程，更好地服务于项目开发。
（ps：感觉可定制性太差。
阉割版的ClearQuest功能不能够期望太高
用 Rational Team Concert 进行变更管理及版本控制
一些相关概念。（IBM的一个新产品就会附带很多新概念。要习惯。
1．工作区 (WorkSpace)
：工作区是提供给用户来浏览或修改组件的地方，我们可以在 My
Repository Workspaces 选项上单击右键来创建，创建的过程中需要选择 Repository
Connection 和项目相关的流，方可创建成功。
2．组件 (Component)
：组件由一个或多个工件组成，比如一些描述网页内容的文档，一些项目中的 Eclipse 插件。创建工作区后，可以选中工作区，单击右键来创建组件，
3．流 (Stream)
：流由一个或多个组件组成，流和组成它的组件可以和一个或多个变更集相关联。流还和项目域相关联，在项目域创建成功后，会自动生成缺省的流和组件。
4．变更集 (Change
：顾名思义就是一些相关变更的集合，变更集只能描述针对一个组件进行的变更，其中的变更会被一起交付给某个流。变更集通常会和某一个工作项
(Work Item) 相关联，比如 Defect，Enhancement（这些工作项可以在项目域中的 Project
Configuration 中定义），和工作项相关联的目的是基于工作项给出具体的关于变更的描述。通常用户要做出变更时，会创建变更集，可以在 Pending Changes 选项卡中选中某个组件，单击右键进行创建。创建后会出现一个 Outgoing
文件夹，里面是生成的变更集，为 Joshua Bell
创建的变更集，单击右键和某个工作项关联后，关于工作项的修改就会反映在变更集中。选中变更集单击右键可以选择交付，挂起，忽略或者撤销当前的变更。变更
集一共分为三类：
1) Outgoing
为当前用户创建，只能选择交付，挂起，撤消或者回滚当前的变更。
2) Incoming
另一用户创建，当前用户浏览时会显示为 Incoming，当前用户只能选择接受变更，
3) Suspended
为挂起的变更，挂起变更的目的是用户停止对变更集的更改，当不同用户的变更出现冲突时，可能会将变更挂起做进一步的调研，对于挂起的变更只能进行撤销或者恢复动作，
通过交付操作，可以使团队的其他用户看到某用户做出的变更。通常来说交付变更的全过程为：
1. 创建变更集
2. 为变更集关联工作项
3. 修改工作项中的描述或相关文件
4. 标记变更集为完成状态
5. 直接交付变更或提交变更给某些团队成员审查
（ps：这个概念类似ClearCase的deliver？
版本控制机制
Jazz 采用乐观锁模型来控制版本，用户无需对要修改的文件进行检出或锁定。用户每交付一次变更，就会增加一个版本。如果两个用户都同时对同一个文件进行了修改，在这种情况下，交付时会有可能发生潜在的冲突。
看完这个文章。大概有个认识了。
是一个项目完整例子。非常不错。RTCE居然自带截屏功能。这个赞一个。
安装的文章：
是一个项目完整例子。非常不错。(需要IBM的账号登陆。注册个就行了)
并且还有在线试用。
企业版可以下载 60 天试用期的免费
试用的时候好像也可以技术支持，不知道有没有回复。哈哈。
一个很重要很直观的RTC太透明了。杀伤力非常大。IBM的自圆其说。
收到的一些其他信息：
RTC用户管理：自己管理，或者集成LDAP管理
多了个web 2.0的RSS Feed功能。订阅功能非常强大。值得期待
可以集成聊天工具，IBM自己的，jpore（开源的，这个不清楚全写），GTalk。目前不支持集成QQ,MSN
RTC用户权限分两层，一层是RTC系统的权限。分5级。一层是RTC系统里面创建的项目里面配置的权限。自己随便配置
RTC创建用户会默认密码同用户名，新用户第一次登录会提示修改密码。以后用户自己也可以修改密码。
RTC支持java代码自定义类似Clearquest，Clearcase的trigger功能（具体不清楚）
work item工作项，可以定义很多工作类型。比如defect，requirement，plan等。这个和传统的不一样。需要消化。
加入web2.0的tag功能。搜索的时候可以搜tag
RTC流程定制直接修改就生效。无须
类似Clearquest的desinger升级
增加了个审计功能。不过需要人手工调配。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：187601次
积分：2966
积分：2966
排名：第10247名
原创：101篇
评论：27条
(3)(1)(1)(2)(3)(7)(22)(11)(3)(2)(3)(41)(1)(4)概述　　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这个强大的工具能够更好地支持软件开发团队的工作，交付更多更好的产品。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：89312次
积分：1326
积分：1326
排名：千里之外
原创：19篇
转载：131篇
(1)(1)(2)(1)(1)(5)(1)(1)(2)(2)(2)(2)(7)(1)(3)(6)(1)(7)(3)(1)(4)(4)(3)(5)(8)(5)(7)(5)(2)(3)(9)(8)(2)(5)(3)(26)(1)(1)(1)(5)