转自：http://www.ibm.com/developerworks/cn/rational/r-cn-whyclearcase/index.html
IBM Rational 的 Rational ClearCase 是软件配置领域的先导，它主要基于 Windows 和 UNIX 的开发环境，并提供了全面的配置管理──包括版本控制、工作空间管理、建立管理和过程控制。
随着软件团队人员的增加，软件版本不断变化，时间的紧缺，多种平台的复杂环境，使得 Rational ClearCase 所拥有的特殊组件已成为当今软件开发人员（工程人员和管理者）所需要的基础工具之一。
Rational ClearCase（以下简称 ClearCase）是业界非常优秀的软件版本控制工具和软件资源配置管理工具，在软件开发过程中，采用 ClearCase 进行版本控制能够实现真正意义的并行开发，提高开发效率。同时 ClearCase 作为商业软件，拥有不断进度，满足开发人员各种需求的动力；但也拥有大型商业软件的弊端，对需求或者缺陷的响应速度慢；以及常被用户抱怨的复杂！
其他配置管理工具，目前最流行的，是 Subversion，这个工具是一个开源的产品，是为了降低公司成本，同时满足开发人员想利用更少的过程，约束以及控制，而采用简化的配置管理解决方案。Subversion 的优点在于简单，方便；但 SVN 也有一些不足之处，因为 Subversion 只是版本管理工具，对于配置管理的支持比较缺乏，例如完善的版本树，便捷的项目级代码管理，代码集成的支持等。
统一变更管理（Unified Change Management, UCM）是第三代的配置管理解决方案，是用于管理软件开发从需求获取到版本发布整个过程中所有变更的“最佳实践”流程。UCM 定义了一个可以立即用于软件开发项目的基于活动的代码变更管理模式。
UCM 模式中最有名的就是 ClearCase 和 ClearQuest 的集成，ClearQuest 中的变更请求（Change Request）关联到 ClearCase 中的某个 Activity 上，然后开发人员修改代码时，必须选择本次修改和哪一个 Activity 做关联，这样变更请求 -> Activity -> 代码，就有了清晰的关联。
在互联网行业，对于“速度”有着疯狂的崇拜，因此在变更的响应时间上要求快！快！再快一点！文档，记录似乎变得都不太重要了，满足用户需求是第一位的，产品质量不可降低，这就造成信息还是必须的，这个时候，UCM 模式带来的好处就凸显：代码变更可审计，简化故障分析的复杂度，为缺陷预防提供详细的信息，提高回归测试分析的有效性，于是文档似乎不重要了……如果多的好处，谁不想要呢？而 ClearQuest 工具在流程管理上的强大，让用户不得不选择 ClearCase 作为配置管理工具；同时简化文档的作用，而把注意力专注到完成项目，完成用户上，也是目前流行的“敏捷”理论所推崇的。
ClearCase 新功能 -- 给互联网行业的用户带来提高开发整体工作效率的机会
如果单独作为一个文件版本管理工具，和其他工具，例如 SVN 做比较的话，ClearCase 没有任何的优势。但 ClearCase 作为商业工具，它有着令人心动的未来：
ClearCase 新版本 CCRC 的出现，让很多使用 Java 为主要开发语言的互联网用户来说，有了更多的选择：作为一个新的 ClearCase 客户端，和开发相关的代码配置管理工作都可以完成；免除了庞大的工具安装，只需要在 Eclipse 中安装一个插件即可；同时插件模式的使用，使得 Java 开发可以和配置管理工作无缝的集成。
CCRC7.1 中，提供了对 Code Review 的支持，通过一个简单的“通过选择器显示更改集”，就可以把 UCM 模式下，任何一个 Activity 所修改的代码查询出来，可以方便的做查看，以及版本比较。这种方式下，可以对任何一个任务修改的代码进行 Review，甚至不是自己所参加的 UCM Project 都可以。
例如开发人员 A 需要 Review 另一个开发 B 在某一个任务上修改的代码，他只需要知道开发 B 的任务 ID 即可：
- 打开变更集视图
（查看图 2 大图）
- 输入开发 B 的任务 ID
- 选择需要检查的代码进行代码审查（Code Review）
（查看图 4 大图）
当大家还在抱怨 Code Review 不好做，不知道这部分代码是和那个需求关联时，这个方案会让 Code Review 变得异常的简单。
从开发人员视角来看，似乎效率就是如何更快的修改代码，但从整个研发模式来看，快速的集成，快速的编译，快速的测试，这些都是效率提升的体现。
ClearCase 在这些方面，结合其他工具，很容易实现相关功能。而其他一般的把版本管理工具，是无法在这些方面有所突破的，除非整个工具支持二次开发。
很多人在接触到 ClearCase 的时候，无不为 "Stream" 这个词伤透脑筋，它和分支有和何不同？它有什么好处？但随之使用的深入，你会发现，无论你的研发模式如何调整，它总是能适应你的各种应用。
举例来说：在互联网行业，一般都有两种不同类型的项目，项目 A 是一个由很多小的需求组成的项目，设计后发现，在代码上分析彼此没有任何冲突，另一个项目 B 则是一个庞大的项目，需求错综复杂，完成设计后，代码关系如同蜘蛛网一样复杂，同一个文件会被多个需求所修改，甚至有类会被重构。
这两种项目，从研发流程来说，应该选择不同的流程，项目 A 需要简单，快速，不需要很严格的评审，以及变更管理，项目 B 需要严格的评审控制，变更控制，避免项目失控。从配置管理策略来说，也应该是适用不同的策略，项目 A 可以把项目中的开发活动统统隔离开，项目的各个任务之间不受影响，用最快的速度完成各自的开发，各自的测试，代码集成后也不会有太多冲突，和集成的问题，因此可以采用集成流 + 开发流的模式；而项目 B 需要尽能的集中，尽早发现不一致，把集成的问题第一时间发现，第一时间解决，避免在项目后期陷入痛苦的集成工作，因此需要每天做集成和编译，甚至每天做自动测试，回归测试，因此可以采用复用集成流的模式，所有开发都复用一个项目流，代码的改动随时会被发现，被解决。
虽然单流模式可能会让项目很“痛苦”，但和集成的痛苦相比，可能是打针和做外科手术的区别。从对持续集成不太深入的了解分析，持续集成就是要让变化尽早的被发现，被解决，而复用流模式，则是持续集成的最极端的场景之一：变化随时被项目组的其他人员感知，冲突随时被解决，否则开发是无法进行下去的，如果加上自动化的集成，自动化的测试，这就是一个典型的项目内部持续集成应用。
这两种模式也有各自的优缺点：
单流模式优缺点：
- 优点：
- 代码修改联系紧密，任何变动，随时被项目组所有开发人员获取
- 开发人员只需要 check in 代码即可，无需二次提交
- 缺点：
- 流的代码质量不可控，随时处于变更状态
- 对流做 Rebase 或者添加子系统，开发的工作同时受到影响，无法工作，时间随 rebase 以及同步的时间长度而定；
多流模式优缺点：
- 优点：
- 隔离开发空间，各自工作不相互影响
- 对集成流做 Rebase 或者添加子系统后，开发人员的工作不受影响
- 集成流的质量得到保证，对持续集成 / 编译 / 测试有帮助
- 缺点：
- 开发人员需要对流模式有了解
- 开发人员需要把代码从开发流二次提交（Delivery）到集成流
- 需要有人对集成流进行管理
在不同的情况，应该根据自己的实际情况选择适合自己的模式，汇总来说，单流和多流模式适合的使用场景如下：
- 单流模式：
- 开发人员工作比较分散，对相互的工作几乎没有影响
- 强调开发速度，对过程中的代码质量不做要求
- 多流模式：
- 开发人员工作相互干扰大
- 项目经常受其他项目影响，需要随时做 Rebase
- 过程中的代码质量受到控制，并对集成流做持续集成 / 编译 / 测试 / 部署
当然流模式的好处，对于互联网行业不仅仅在开发流和集成流的区别，还有 Rebase，基线，以及对于产品模式和项目模式的同时支持等等。总的来说，“Stream”就是一个大草原，你可以按照自己的目标和具体需求，规划自己的道路。
郭士纳在《谁说大象可以跳舞？》中描述 IBM 和其他公司的不同之处，就是在于提供完整的解决方案，而不仅仅是某个环节的最佳实践。因此我们可以看 IBM Rational 在软件公司的全套应用：需求管理，架构分析，开发设计，缺陷管理，持续集成，自动化测试，甚至是性能测试，代码走查……
当 ClearCase 和相关工具结合起来，你会看到一个完整的研发工具平台，可以满足任何研发环节的应用。虽然这些工具都是商用工具，有的还比较复杂，但随着时间的发展，相信 IBM Rational 会逐步整合出一个简单有效，统一的研发平台，再配合成熟的，有技能的人员，加上完善的流程规范：稳定，而且平衡的质量三角形就会呈现在你的面前。
例如目前公司在试点敏捷方法，其中对于持续集成有工具上的要求，我们采用开源的持续集成工具 CruiseControl 管理持续集成的策略，但我们的代码还是保留在 ClearCase 的 Stream 中。CruiseControl 可以自动的获取 ClearCase 的代码变更，然后执行编译，测试，部署等等活动。
配置管理工具是任何软件公司都必须的，只是需求不同，造成功能不同而已。
因此没有了 ClearCase，你也需要选择另一个配置管理工具，例如 SVN，或者自己开发一个的配置管理工具。
但有两个问题需要在决策前考虑：工具的开发是否是你的主业？你做的会比商业工具更好吗？只是如果选择了商业工具，那么商业工具应对变化缓慢的问题，在这个速度至上的时代，的确是需要工具厂商认真对待的！
不知道是否是因为出身名门的缘故，IBM 产品给人的印象就是庞大，复杂。在 ClearCase 这个产品中，虽然有很多很多好的功能，但对于不同的人来说，也许甲只用两个功能，乙用另外三个功能，但两人都需要把 ClearCase 安装完整，同时在使用的时候，由于功能的庞杂，难免造成用户抱怨：我需要的功能很简单，但为什么工具要规定我必须要这么做，太复杂了！
如果 ClearCase 能针对不同的人，提供不同的版本，或者说针对 Eclipse 的不同插件，例如普通开发，就是版本管理；技术负责人，需要 code review，编译集成等工能插件；集成人员需要提交，Rebase 等功能插件……这样可以针对不同人员的需求，提供轻量级的功能应用，同时易用性又可以更加贴近不同的用户，做的更好，这样的产品是否会有更多人喜欢？
互联网是一个全世界都在关注的领域，但从 IBM Rational 的产品来看，似乎没有完全跟上这样一个步伐。举一个简单的例子，我们是使用 Eclipse Java EE 的版本，在 Eclipse 中有一个重构（Refactor）功能，当我们在使用这个功能出现问题时，ClearCase 的开发人员和技术支持人员，似乎都不了解这个功能，这样就无法给用户提供及时的解决方案，用户的抱怨就多了，满意度自然就降低了。
当你面对一个选择：一个功能弱小，满足当前需求，但不会出问题的系统，和一个功能强大，满足未来五年需求，但经常有各式各样，大大小小问题出现的系统，决策者会选择哪个呢？
一些看的长远的公司应该会选择后者，但这样的选择是有前提条件的：出现问题没关系，但解决问题的速度要快！就如同当下流行的一个比喻：在汽车飞驰的状态下，如果轮胎出现了问题，要在不减速的情况下，更换轮胎，只有这样才能保持对竞争对手的压力，保证自己的市场份额。
从 ClearCase 在公司的实际使用来看，我们选择了后一个方案，但出现问题后，解决的速度令人不满意。开发人员都知道，作为一个配置管理工具，如果出现一个重大问题，也许是工具问题，也许是方案问题，也许是执行问题，就会意味开发人员无法正常工作，甚至造成代码出现问题。作为向服务转型的公司代表，IBM 应该在这个方面做出表率：无论问题是由什么原因造成的，IBM 应该协助用户去分析问题，解决问题，只有这样，才能赢得用户的信任，才能和用户一同成长。
ClearCase 无数配置管理中的一种，它有着令人着迷的功能，也拥有很多让开发人员抱怨的弊端，作为配置管理员，或者管理研发工具的人员，这些都需要了解，然后根据自己公司的实际状况，以及暴露出来的问题综合考虑，选择真正适合自己的工具。
无论选择那种配置管理工具，在工具切换时一定要做好充足的，甚至过分的准备，包括实施前的介绍沟通，实施中的培训，实施后的技术支持，这样才能得到良好的回报。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780914/viewspace-625678/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14780914/viewspace-625678/
扫一扫
4378
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
