SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 5463|回复: 1

[推荐] 基于CC UCM与CQ集成与基于RTC的两种软件配置管理的比较

[复制链接]
发表于 2011-12-6 18:26:59 | 显示全部楼层 |阅读模式
本帖最后由 技术狂人 于 2011-12-7 10:41 编辑 & j/ e& a1 z; F$ [$ }  _7 n) b
5 Q9 W1 U/ x. }% }! M
1. 引言# h2 i/ c- g! r5 I# x( [
软件配置管理(SCM)是软件工程范畴内的重要内容,它贯穿于软件开发的整个生命周期。适当的软件配置管理解决方案可以为软件开发提供一套适合的管理方法和活动原则从而大大提高软件开发的生产效率。软件配置管理可以概略的分为以下几个方面的内容:版本控制(Version Control)、工作空间管理(Workspace Management)、过程管理(Process Management)、缺陷追踪(Bug Tracking)。本文根据在实际生产环境中的一些使用经验从以上四个方面对目前常用两种软件配置管理解决方案做一个浅显的比较:一种是 Rational ClearCase UCM 与 Rational ClearQuest 集成实现的解决方案,另外一种是通过 Rational Team Concert(RTC)实现的解决方案,以期能够帮助读者对两种产品的特点有一个认识,并在此基础上帮助读者确定一款适合自己产品的软件配置管理工具。- W8 O+ I! n: D$ g

3 \' Q7 K* t1 c' e, o3 Z% k

% \# [+ d- w2 _1 q4 U& z2. 两种解决方案的比较3 _& Y- Q/ o3 y& `1 G$ Q
在 ClearCase UCM 与 ClearQuest 集成实现的解决方案中,ClearCase UCM 主要涵盖了软件配置管理中的版本控制,工作空间管理和过程管理三个方面的内容,而 ClearQuset 则主要是完成缺陷追踪的工作。所以版本控制,工作空间管理和过程管理方面,我们着重比较 ClearCase UCM 和 RTC,而在缺陷追踪方面则简单区别一下 ClearQuest 与 RTC 的特点。
+ F4 k; n9 V: J1 a2.0 基本概念
* K, T' L0 B+ ~这里首先对 ClearCase UCM,ClearQuest 与 RTC 的一些基本概念做一下简单的对比。以方便读者可以更好地阅读本文后面的内容。% S& M  ^7 U: I* W5 X" B
+ i0 R9 z1 A6 e) ]
表 1. 基本概念的比较7 s" u: U! _: v% g8 }
ClearCase UCMRTC
Project VOBRepository
VOB-none-
ProjectProject (RTC projects do a lot more)
Project and Stream PolicyProcess Configuration
Compartment = VOBCompartment = Project
Static Stream HierarchyDynamic Stream Hierarchy
Integration StreamStream
Development StreamRepository Workspace
ComponentComponent
Change SetChange Set
Snapshot or CCRC ViewLoaded Repository Workspace
Dynamic View-none-
Composite BaselineSnapshot
Component BaselineBaseline
DeliverDeliver
RebaseAccept changes from baselines of a snapshot
-none-Accept Latest
  f+ j/ W' ^# k, c# ?! m


1 B) ]( `( f: a$ O  P/ o# X/ M
! u2 y" }( [8 h( S! t2 R" z$ |9 {" K2.1 版本控制! K- Z5 O% G+ ]4 k  Q* d
版本控制是软件配置管理的核心和基础,版本控制的对象是软件开发过程中所有软件元素。版本控制的主要目的在于对整个软件开发周期内的所有软件元素的发展过程提供一种追踪的手段,以便我们在需要时可以回溯到某一时间点的版本。
- o8 P' Y7 M9 m* A2.1.1 ClearCase UCM 的版本控制
& g$ r+ t+ `- P9 l$ l$ G0 s% s6 ~ClearCase UCM 通过元素(Element),版本(Version)以及版本树(Version Tree)等对象实现版本控制。
6 l) e1 }& h) ^  s, E1 P5 e, eClearCase UCM 中所有受控的文件或者目录都称之为元素,这些元素存储在 VOB(Versioned Object Base) 中。版本是元素在某一时刻的状态,每一次检出(Checkout)和检入(Checkin)都会生成元素的一个新的版本。对于某一元素的版本变更过程,ClearCase UCM 用版本树做了直观的描述。在版本树中,每一个节点代表元素的一个版本,根节点是元素的初始状态,叶节点是元素最新的版本状态。& n* ~4 Q* d- z

0 i3 g7 T) Y* b) ]# a% l+ G& }$ A( j图 1. 版本树示例
! W' I  _1 R+ q6 l ; X! f* v# D, {# A4 w2 j+ W- I$ g0 b
最简单的版本树只有一个主干分支(Branch)。而在并行开发模式下,元素的版本树可能会有多个分支(如图 1),因为不同的开发人员可能对同一元素做了修改。尽管这些分支之间的版本的变更相互之间并不影响,CearCase UCM 还是允许在同一元素任意两个版本之间进行比较,这非常有利于开发人员得到元素在不同分支上做的修改的差异(如图 2)。
. g* q, n* r# ]% P% L1 b# F/ X. P) ]! x9 O
图 2. 两个版本比较5 d5 u" q: J- B4 G* R
7 `, X) O; x/ p
元素在不同分支上的版本会在发布(deliver)或者变基(rebase)的时候被合并(Merge)到一起。合并是 ClearCase UCM 版本控制中一个核心操作,下面介绍一下 ClearCase UCM 中的合并是如何完成的。在合并操作中,所有需要合并的版本称为源版本(Source Version),这些源版本最近的共同祖先称基版本(Base Version),需要合并到的分支上的最新版本称为目标版本(Target Version)。ClearCase UCM 的合并会通过以下操作来完成:) X% j, k! z0 `) u/ A  e1 M( @
  • 确定基版本;
  • 每一个源版本与基版本相比较;
  • 没有被任何源版本修改的行被直接复制到合并输出文件当中;
  • 任何与基版本相比被某一源版本修改过的行被复制到合并输出文件中;
  • 任何与基版本相比被某几个源版本同时修改过的行,需要首先解决各源版本之间的冲突然后进行合并;
  • 合并输出文件作为目标版本分支上目标版本的下一个版本。
    , L- c. O8 k* h* |# q

9 N, {) U1 x  I% z2 T2.1.2 RTC 的版本控制
6 s0 f& z  @3 k6 h" ?- E
在版本控制方面上,RTC 与 ClearCase UCM 有很多相似之处。RTC 采用乐观锁模型来控制版本,开发人员无需对要修改的文件进行检出(Checkout)或锁定(lock)。开发人员每交付一次变更(change set),就会增加一个版本(如图 3)。如果两个开发人员同时对同一个文件进行了修改,交付时会有可能发生潜在的冲突。而通常的为了更有效地追踪变更集,一般都会与一个功能更强大的工作项(work item)进行关联。和工作项相关联的目的是基于工作项给出具体的关于变更的描述。RTC 中对于文件并没有明确的版本号定义,例如版本 1.0、1.1、1.2 等等,它通过查询文件的历史查看当前流(stream)下的文件的修改历史,也就是说在每一个流下的文件都是从最初始版本号开始开始改变。而且在文件的历史工作栏中,RTC 提供了更直观的图形结构显示开发人员是基于哪个版本的文件上工作,并在何时解决的文件冲突的。7 U3 L2 G( B: ], B- p0 x- ?4 ^9 q: O
/ {' D) h  e6 C5 s, h1 c- I$ H2 y
图 3. RTC 的版本控制
% Q/ I. g' S" ?7 E , {1 v! H$ P3 F4 ?
此外 RTC 不仅可以单独比较两个不同版本文件之间的差异,也可以通过 RTC 的 Annotate 策略查看文件某一版本与初始版本之间所有变更集。在通过 Annotate 打开的文件的左边栏,可以看到一些固定的按钮,将鼠标右键移动到按钮上,可以显示出与变更集相关联的工作项的详细信息(如图 4)。
  o/ a7 C0 b* S$ ?" E2 C; d
- l3 b5 {1 q" d& ]% m图 4. RTC 中 Annotate 样板+ s$ u! [( ]! r. C. E
  W3 E$ k3 i- u' p# z' Y  r
在合并策略上,RTC 更为直观,并提供了三种选择方式:# ^( d7 C  N# p2 r4 k" k
  • 以自己本地的文件为目标版本,放弃服务器上的变更;
  • 以服务器上的文件为目标版本,放弃本地的变更;
  • 合并本地文件和服务器上文件;8 R1 F3 [) L; s& `
文件的合并历史信息可以显示在 RTC 历史选项卡中,如上图 2 中,版本 5 是直接基于版本 4 上进行开发,版本 7 是间接基于版本 4 上进行开发,最后版本 5 和版本 7 的改动在版本 8 上进行了合并。* R9 F/ N' k0 y2 H9 V' ]5 t

9 d0 x9 {% Q, o7 T- C: k2.1.3 小结
  |% |/ t3 c4 g/ Z3 W% M& H8 D+ \
ClearCase UCM 中提供了较 RTC 更为具体直观的版本以及版本树的定义,而 RTC 中版本的概念相对来说更为宏观。ClearCase UCM 对每一个元素的版本都做了详细的定义,基于版本的操作非常丰富,其版本控制的功能十分强大,RTC 则在易用性上表现的更为突出一些。
& ^$ C& s* ]* l2 C

4 E, H/ R6 c% T. O0 S. J- h. j9 Q9 z! T7 ?* d7 [! H3 I
2.2 工作空间管理1 }3 ]' f% L. M- k
工作空间是由项目中所有软件元素的某一合适的版本组成的一个开发环境,开发人员在工作空间中完成软件开发,修复缺陷等任务。0 Q' f8 e; J; `* H$ _1 {$ ~

, D7 e" N' J5 V6 v, h2.2.1 ClearCase UCM 的工作空间管理

0 i5 h' ?+ I+ v/ AClearCase UCM 中的工作空间由视图(View)和流(Stream)两部分组成。
5 K+ |# J$ F) K. L; w( Z- D视图是项目中所有软件元素某一版本的呈现。流是由基线和基于基线的活动(Activity)组成,基线决定了在元素在视图中的版本。
# [. K2 b3 y9 g2 A" ]$ ?# G5 \多流(Multi-Stream)的项目在 ClearCase UCM 的应用中是最为常见的。这里以多流的项目为例介绍一下 ClearCase UCM 的工作空间管理。! M  R3 D/ _* A, o' W8 e
多流的项目中通常有一个集成流(Integration Stream)和多个开发流(Development Stream)。集成流和相应的集成视图(Integration View)组成了项目的共享工作空间,开发流和它相应的开发视图(Development View)组成了开发人员的私有工作空间。
! r2 Z( }6 v, P. H1 T( P% b, p- C, w- f8 Y% @) U
图 5. ClearCase UCM 中工作空间的搭建流程# x6 k" d) I' |1 |) r0 x
) E( M% Y; z8 d$ a/ D" r( r: A
图 5 中给出了在一个多流项目中工作空间的搭建和更新的流程:开发人员在加入(Join)项目时创建一个集成流的子流(Child Stream)以及相应的开发视图,从而获得一个私有的工作空间;随后,开发人员寻找并设定相应的活动用以记录其将对软件元素进行的变更,变更完成后,开发人员将记录变更集(Change Set)的活动发布到共享的集成流中;而后,开发人员变基自己的开发流以得到其他开发人员发布的最新的变更集。在整个软件生命周期内,这个过程不断循环往复。/ l3 c) U7 y% b; ^" A
发布和变基是 ClearCase UCM 工作空间管理的两个核心操作。下面就来详细看一下。9 G/ b9 N! B+ |- N" N% w
开发人员通过发布操作来将自己完成的变更内容提交到集成流。在发布变更内容之前,开发人员首先需要准备好自己的工作空间并预览(Preview)将要发布的活动。工作空间的准备主要有以下几个方面的内容:如果集成流上已经创建了新的推荐基线(Recommend Baseline),那么开发人员需要首先变基自己的开发流到新的推荐基线;如果开发人员创建的集成视图是快照(Snapshot)类型的,那么开发人员需要首先更新集成视图并处理可能存在的劫持(Hijack)文件;确定所有需要发布的内容都已经检入。准备工作完成后,开发人员开始执行发布操作,发布操作会比较元素即将发布的版本和元素在目标集成流中的版本,如果需要将触发 ClearCase UCM 合并管理工具,合并管理工具会自动合并尝试(Trivial)类型的差异,但是对存在冲突的差异则需要开发人员手工进行合并。在完成发布之前,开发人员还需要进行测试以确保即将发布到集成流的内容不会导致构建(Build)的失败。确保即将发布的内容没有任何问题之后,开发人员可以完成发布工作,在这个阶段发布操作会验证合并的差异并将其检入到目标集成流中。
+ ]! J+ j7 Z" N1 `7 a再来看一下变基操作。在一个多流的项目中,开发人员通过变基操作来更新自己的工作空间。变基操作会帮助开发流更新到指定的基线,并同时更新相应的开发视图。执行变基操作前,开发人员需要首先检查开发视图中所有检出的元素,做相应处理后检入;之后,可以选择目标基线开始变基操作,在变基操作的过程中,如果目标基线中存在对相同元素的修改,需要首先合并差异;当所有的差异和冲突合并完成后,开发人员需要验证没有发布的内容可以跟 rebase 得到的新的内容一起被正确的构建出来;最后完成变基操作,检入所有合并的结果。
& [4 g" r+ r+ b; m8 |- X9 `4 s4 k, ?
2.2.2 RTC 的工作空间管理

' I/ v$ y  z+ K4 b; }. D) Q' ARTC 的工作空间一般是在流的基础上创建,并分为存储工作空间和本地的工作空间两部分。但是需要注意的是 RTC 概念中的流相对应于 clearcase 中的集成流,工作空间相对应于 clearcase 中的开发流。
) f% ]3 K% T4 }当开发人员创建其工作空间时,首先会在服务器上创建存储工作空间(repository workspace),然后会根据开发人员的选择在本地创建一个存放代码的本地工作空间(local workspace)。) G% K% k( c+ Q
: I; |4 E. k# Y
图 6. 创建工作空间7 M' n0 \) E$ l: X3 Q, P

( b: y* \9 n( u1 l. k当开发人员在本地工作空间工作时,首先会在存储工作空间创建副本文件,然后将存储工作空间的副本下载到本地工作空间:
2 w' z* h% H9 B" W" X同理,当开发人员需要把开发的代码上传到流上的时候,也需要先上传到存储工作空间,使得存储工作空间和本地工作空间保持同步,然后再把存储空间与流之间的差异上传到流上:2 q" i- z$ `4 ^6 k9 n
7 L4 w. K, d3 b+ ?$ \& `- i9 W
图 7. 同步存储工作空间和本地工作空间( B6 }6 |3 w2 x& s! ^3 k
& k3 c" e3 f: i! [) n# S5 X
RTC 流和本地工作空间的改动会实时的显示在 pending changes 选项卡。每次刷新 pending changes 选项卡的工作空间,存储工作空间便会的与其依赖的的流和本地工作空间进行比较,并将差异文件直观的显示出来:
/ K! Y- t/ F7 n9 I
  • 差异在本地工作空间,而没有上传到存储工作空间的被定义为 unresolved。
  • 差异在存储工作空间而没有上传到流上的被定义为 outgoing。
  • 差异在流上,而不在存储工作空间和本地工作空间被定义为 incoming。
    ' t+ }  Z) X- I, {2 z
在 RTC 工作空间,有很多有用的符号帮助用户更直观明了的了解每个动作的含义,例如代表了冲突文件;代表了需要上传的修改文件;代表了需要更新的修改文件; 代表了要删除的文件;相反的代表了要添加的文件等等。
3 w4 |$ K  i. q: E5 z5 SRTC 的工作空间的查看权限可以设置为私有的(private)、公众的(public)、范围的(scope)。公众工作空间其他的开发人员可以通过搜索看到该工作空间;私有工作空间只能被创建者所查看;而范围工作空间则能被一个小组的开发人员所看到。
+ K7 C2 k1 x  h& {9 p$ w- e! F; c
% R& L; W6 i2 G) U4 ^7 x& [2.2.3 小结

% @0 B# v2 \" f" z5 ?  tClearCase UCM 与 RTC 二者工作空间在实现上各自特点仍然很明显。ClearCase UCM 通过流和视图的概念来完成对工作空间的定义,与 RTC 直接定义的工作空间相比较,开发人员可以在流和视图上完成的操作相对丰富,但是也相对复杂;ClearCase UCM 中可以在集成流上的发布活动中看到其他开发人员已经提交的变更内容,不过开发人员只有在执行变基操作后才能获得共享工作空间内其他开发人员提交的内容,显然这潜在的可能会带来一些相对复杂的变更冲突,令人欣喜的是 ClearCase UCM 对此提供了足够强大的解决机制;在 RTC 工作空间管理的实现中,共享工作空间的更新对开发人员来说是实时获取的,这有利于第一时间解决可能存在冲突。
, G0 u- b1 \, g- v$ ?+ w5 c; y3 J

% I! l' ]3 M; s
, c% ~3 O5 @# u3 L2.3 过程管理
- n: F0 n9 t4 h% Y! H过程管理是在软件开发生命周期进行中处理发生于软件元素的各种操作,主要包括变更管理和各种策略控制等两方面的内容。& s* e' ?) R4 }) D

* e; S) V7 S: p6 t% L6 a' m2.3.1 ClearCase UCM 的过程管理

+ s4 O/ H6 s" e在 ClearCase UCM 与 ClearQuest 集成的软件配置管理解决方案中,变更管理主要是通过基线和活动来实现的。' b' A1 N, V. ?. Q+ c! t% }
基线可以看成是流在某一时刻的静止状态,它由所有元素在基线创建那一时刻的版本组成,并且相互之间有一定的依赖关系。
. e" o1 _  ]' O! F, s活动有以下几部分组成:活动头(Headline),活动创建者(Creator)和变更集(Change Set)。其中变更集记录了开发人员为完成指定任务(Task)而在创建的元素的所有版本。. l& _) S4 Q( a' P/ U: z
在 ClearCase UCM 和 ClearQuest 集成的软件配置管理解决方案中,一个活动通常指的是两个相互关联的对象:ClearCase UCM 中的一个活动对象和 ClearQuest 用户数据库中的一条记录。而且一个活动的创建是有特定的顺序的。首先在 ClearQuest 中创建一个某种已经对 CC 启动的类型的记录,当开发人员在视图里指定一个活动时,一个活动对象就会在该视图依附的流中被创建出来。被创建的活动对象与 ClearQuest 用户数据库里的记录是相互关联。8 e2 D: q; Q5 A! p( F. {
ClearCase UCM 中的变更管理的过程在形式上可以直观看成是一个基线不断更新的过程。在项目开始的时候,创建一个初始的基线作为项目开始的起点;在初始基线的基础上,开发人员将完成的任务以活动的形式发布出来;在某一时刻新的基线被创建,开发人员在新的基线的基础上,开始完成新的活动。图 8 给出一个基线更新的具体过程。. V; I1 G4 A* Y; z2 e; \9 m

9 c0 e$ ~7 o0 P: Y7 Z6 s图 8. ClearCase UCM 中基线的更新过程  }/ z. v! ?! D# V# d7 [9 z

& N) }- o3 o; l+ ]% L1 N  A, S% \4 yClearCase UCM 提供了多种策略以增强软件开发的过程管理,主要有以下几种:( }' `: T5 c. M: m( B( l
  • 面向组件和基线的策略
  • 默认视图类型的策略
  • 修改项目和流的权限的策略
  • 面向发布操作的策略
  • 面向到非默认目标的发布操作的策略4 h3 w7 i* W7 a+ b
- z; n+ ?% ?6 ?. p% {# ?
2.3.2 RTC 的过程管理
3 u0 I5 H9 H9 g9 E0 a8 v) ^
RTC 使用工作项来追踪不同基线(baseline)之间的变更。通过交付操作,可以使团队的其他用户看到某用户做出的变更。通常来说交付变更的全过程为:
5 @5 J6 Y2 n/ f4 a' F" f1. 创建变更集
' S  d$ t( I3 w, J; F. k$ r! T2. 为变更集关联工作项$ @4 S5 M& ^5 {7 x
3. 修改工作项中的描述或相关文件$ o4 G6 }5 A0 I$ G3 }
4. 标记变更集为完成状态8 o( W: n$ t2 P: Q  s# X3 g' c
5. 直接交付变更或提交变更给某些团队成员审查, `5 E* t& p; y/ G- M# U2 N5 u
在安全策略方面,Jazz 平台提供了 4 种用户权限可供选择,分别是:, e  v& T; b5 [/ S; `7 ?- B
  • JazzAdmins: 存储库的管理员,对于存储库具有完全的读写权限,可以对存储库内的数据进行任何操作 ;
  • JazzDWAdmins: 存储库的管理员,对于存储库具有完全的读写权限,可以对存储库内的数据进行任何操作 ;
  • JazzGuests: 对于存储库只有读权限的 Jazz 用户 ;
  • JazzUsers: 对于存储库具有常规读写权限的用户,如可以更改项目域,流程模板,但不能创建,可以创建或修改团队域,构建定义等等 ;0 U* H3 \1 `4 [; c4 C9 K$ \/ v
RTC 的 JazzUsers 安全访问策略主要是通过定制项目属性完成。在项目过程配置中,RTC 可以创建不同的角色,并赋予不同的角色不同的权限。对于角色的权限控制,RTC 分为两大部分,项目级别(project configuration)和小组级别(team configuration)。在项目级别上的配置将会影响整个项目,而对小组级别上的配置只会影响小组的成员(如图 9)。+ n) @) r7 d6 G, h3 C% W' |5 L
" l- F5 a& G8 ?' L: ]
图 9. RTC 的 JazzUsers 安全访问策略: ~! a* C% l7 i- ~
" m( |6 H% }* |6 d+ u0 U: s8 r
对于代码的访问控制,RTC 根据需求将项目分为中心项目(Hub project)和几个分项目(compartment projects)。中心项目控制所有的计划定制、流、报告和提交编译等;分项目仅仅包含组成流的组件,并控制对组件的访问权限。每个组件属于一个工作小组,只有工作小组的成员和超级用户拥有权限查看代码的权限。而对于中心项目的并不在工作小组的成员,其角色一般被描述为项目所有者,并没有查看代码的权限。5 R. q. v. x( D1 ~# w
对于工作项的控制,RTC 提供了一种时间线(timeline)的方法。每个小组与一个时间线进行关联,通过对时间线的配置,来约束小组成员在某个时间段所拥有的权限(如图 10)。  r- d9 S7 E! o' D

; U$ Z' Y1 N4 v# [$ ~% a图 10. RTC 中的时间线配置/ d0 v/ B9 S1 l' M8 c( M5 h. y
$ Q$ _* Y0 T1 D1 t6 Z- S

3 g* V* X5 N7 ]
3 ]5 m+ ]; t4 {. v; F# {/ @
2.4 缺陷跟踪: r3 E  ~6 l( A$ Q  S: y
缺陷跟踪处理在软件开发生命周期中针对于产品的新的需求或者缺陷,缺陷管理将相应的软件元素与这些需求或者缺陷关联起来,并对为满足需求或者解决缺陷而引起的变更进行管理。软件配置管理的策略因产品特点而已。我们要根据软件产品自身的特点制定相应的软件配置管理策略进而选用适合的工具。! B) K- {: t$ f$ z+ d+ f
1 k# [5 f2 Y+ I) x7 l( D
2.4.1 ClearQuest 的缺陷跟踪
4 H. o; j, {! Z2 R! W  s! b/ @, {/ c
ClearQuest 具有十分丰富强大的缺陷跟踪的功能。将 ClearQuest 与 ClearCase UCM 集成到一起可以提供更为丰富更为强大的软件配置管理解决方案。实现二者的集成需要在 ClearCase UCM 和 ClearQuest 两端分别做相应的配置。在 ClearCase UCM 端主要是保证项目的 ClearQuest 属性是启动的,而在 ClearQuest 端则需要保证相应的数据库 schema 和记录类型是启动的,配置的过程并不复杂,而且相关的文章多见诸版面,本文这里不做过多赘述。二者的集成的实质是讲 ClearCase UCM 的元素的版本与 ClearQuest 中的变更请求之间的关联。
8 \6 Q) D$ p% `0 W' N/ F
. k) [4 A6 p3 _2 k5 r4 y0 [/ \9 G2.4.2 RTC 的缺陷跟踪

$ ^" |* k0 C- j+ R" O2 c& pRTC 通过工作项(work item)进行缺陷跟踪。RTC 的核心是基于工作项的沟通协作。在过去没有一个好的工具的时候,大量的精力都花在通过电子邮件、文档、绘制各种报告等进行沟通上了。但这些都不能解决这样一个问题,就是所有的文档和工作依然是脱节的。而通过工作项机制,在 RTC 中,开发人员完全可以将全部的需求、代码开发、测试、缺陷跟踪等内容作为工作项的一部分进行统一管理。工作项有不同的工作项类型,如:任务、缺陷、故事、变更等,用户可以根据需要自由增加和定制新的工作项类型。每一种工作项类型都有自定义的字段、状态转换矩阵(State TransitionMatrix),我们还可以定制查询、编辑界面,以及工作项在不同团队、不同迭代中的权限与行为等(如图 11)。如何定制工作项需要大量的篇幅描述,在这里我们不多做赘述。
0 c, v' S4 }8 O$ [- P" J
8 [; G- c/ ?# M9 x图 11. RTC 中工作项
/ M7 B# B/ ]0 f: ?1 N$ y# W , @/ ?% S# x) G- ^
每个工作项都会被赋予一个唯一性的编号。工作项的工作流程可以通过管理员进行定制。每一个工作项的功能更加强大,可以在工作项中添加附件、链接、注释等,并记录任务的历史、工作期限、优先级等。' x' c. F' \. R( n% I6 B


  C  p; l, i6 y, V) M
9 V) Q- k. m. p- w4 l+ P4 l$ F3. 总结
1 A5 O. A7 G. GRationalClearCase UCM / RationalClearQuest 作为一种传统的软件管理解决方案,提供了十分丰富而强大的软件配置管理功能。Rational Team Concert 是新兴崛起的软件配置管理解决方案,相对来说它具有概念简单、容易操作,易于安装和管理,并与工作项、构建等紧密追踪等特点。同时,二者都提供了强大的并行开发(Parallel Development)和跨地域开发(GDD)支持功能。/ |4 A. g/ O: P5 p4 ?0 z

8 V4 k2 F+ e. ]: n4 j. J% g就目前而言,Rational Team Concert(RTC)技术可以看成是 Rational 现有产品如 ClearCase、ClearQuest 等的重要补充,是一个为敏捷开发团队量身定做的、易学易用的团队协作开发产品,对于需要更加先进软件配置管理能力的企业和团队来说,他们可能会选择使用 ClearCase 和 ClearQuest。需要特别指出的是:RTC 提供的强大互通集成能力允许在一个企业中可以同时使用 RTC 和 ClearCase 和 ClearQuest,甚至 subversion 等其他的配置与变更管理系统。
( @: [0 Q! `& c

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
 楼主| 发表于 2011-12-6 18:38:22 | 显示全部楼层
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

SCMLife推荐上一条 /1 下一条

QQ|小黑屋|手机版|无图版|SCMLife.com ( 京ICP备06056490号-1 )

GMT+8, 2023-3-20 17:11 , Processed in 0.070822 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

快速回复 返回顶部 返回列表