ClearCase是否适合我们的开发流程？ [英] Does ClearCase fit our development process?

问题描述

所以，让我描述一下我们目前的情况。我们是一个由经验丰富的Java开发人员组成的小型团队（6），却迷失在一个庞大的IS团队中，该团队主要由SAP和Siebel配置程序组成。

而所有其他团队目前都在使用VSS，主要是跳伞系统，我们的团队已经切换到Subversion（也评估了DVCS），因为它最适合我们的敏捷方法。

现在，每个人都被要求使用ClearCase，并且所有迁移工作都由VSS用户承担，因为它们是用户的最大一部分。

由于我们自己一个人，并不真正了解ClearCase，我们有些担心它不会适合我们当前的工作流程。

目前，这是我们每天的工作方式：

• SVN存储库遵循/ trunk，/ branches，/ tags结构。


• 每个开发人员在存储库中都有自己的沙箱，用于测试和原型制作。


• 我们集中使用分支进行新功能开发，并将其合并在一起在将它们重新推广到主干之前，需要进行一些集成测试。


• 在Java中工作，我们习惯于进行重构，而Eclipse对此提供了很大的帮助。每天都会完成许多类和程序包的重命名。


• 根据项目的发展方式，某些项目可能会被重用，从而导致一个项目拆分为多个项目，原始项目仍保持集成状态通过svn：external属性。


• 我们对某些元素使用关键字替换，因为这是一种非常简单的方法，可以让测试人员知道他正在测试的修订版本。


• 我们的Subversion存储库链接到Hudson，用于运行测试套件并通过标记它们来推广有效的构建。

我对ClearCase所了解的一切目前，我们必须通过CCRC（或通过其eclipse插件版本）使用它，并且强烈建议我们将大多数项目链接到ClearQuest项目以进行问题跟踪管理。

您能启发我们有关ClearCase替代Subversion的程度如何，哪些概念完全匹配（我不在乎同义词，但实际上是关于概念），以及w

谢谢。

解决方案

首先，这是您可以阅读的有关ClearCase的几篇文章：

• 每个开发人员应了解的基本clearcase概念是什么？


• 如何利用Clearcase的功能


• ClearCase的优点/缺点

现在：

• CCRC表示 Web视图，即ClearCase上的快照视图专用的Web服务器...您最好在台式机和该服务器之间拥有良好的局域网。




• 分支机构是ClearCase中的一等公民，给定一个给定的ClearCase视图（这里是ccweb快照）将仅使您可以访问一个分支。如果您习惯一次在多个分支上工作，那么您将需要多个视图。




• 所有操作都是按文件进行的，因此使用时的想法
  
  我强烈建议在 common 分支上工作，以实现多个开发人员想要解决的给定开发工作
  
  如果他们想要私有分支和沙箱，则可以设置在其ClearCase视图内的Git视图没有问题。
  
  （注意：快照视图不能视为沙盒：签入时一个文件，其他所有开发人员在更新其快照视图时都会看到您的更改）




• ClearCase Eclipse插件确实支持重构。




• ClearCase并不真正支持svn：external的概念，除非通过链接。或通过UCM基线依赖关系。
  
  应该知道，使用二进制依赖关系比使用源依赖关系要容易：如果您的外部对象是要包含下一个项目的数千个源文件，它将在ClearCase中很麻烦（由于更新太长）。如果包含几个jar或dll，则速度更快（加上那些将实际部署的jar或dll）。




• 如果您使用的是UCM ，则不可能将代码从一个组件移动到另一个组件。您将必须 clearfsimport 是新标识的公共组件中的主要标签。




• 注意：RCS关键字替换为通常认为...邪恶 ;）我建议使用一个单独的文本文件，其中包含相关重要文件的版本或标签。

So, let me describe our current situation. We are a small team (6) of experienced Java developers, lost in a big IS team that is composed in majority with SAP and Siebel configurators.
While all the other teams were currently using VSS, mostly as a vaulting system, our team had switch for Subversion (after evaluating DVCS as well) as it best fits our agile methodology.

Now, everyone is asked to move to ClearCase, and all the migration effort is put on the VSS users as they are the biggest part of users.
As we are left on our own and don't know really ClearCase, we have some fear that it won't fit our current work process.

Here is currently how we are working on a daily basis:

• SVN repository follows the /trunk, /branches, /tags structure.
• Each developer has its own sandbox in the repository, for testing and prototyping purpose.
• We intensively use branches for new feature development, and are used to merge them together to do some integration testing before promoting them back to the trunk.
• Working in Java, we are used to do refactoring, and Eclipse is a great help for that. A lot of classes and packages renaming is done everyday.
• Depending on how the projects evolved, some pieces may be reused, resulting in a split of a project in several project, the original remains integrated through the svn:external property.
• We use keyword substitution for some elements as it's a extremely simple way to know for the tester what revision he's testing.
• Our Subversion repository is linked to Hudson for running test suites and promote valid builds by tagging them.

All that I know about ClearCase for the moment is that we'll have to use it through CCRC (or via its eclipse plugin version), and that it is highly encouraged that we linked most of our projects to a ClearQuest project for issue tracking management.

Could you enlighten us about how well ClearCase will substitute our Subversion, what concepts have an exact match (I don't care about synonyms but really about concepts), and what kind of changes could you foreseen in the whole process.

Thanks.

解决方案

First, here are a few posts you could read about ClearCase:

• What are the basic clearcase concepts every developer should know?
• How to Leverage Clearcase’s features
• ClearCase advantages/disadvantages

Now:

• CCRC means "web views", i.e. snapshot views on a ClearCase-dedicated web server... you better have a good LAN between your desktop and that server.

• branches are first-class citizen in ClearCase, meaning one given ClearCase view (here a snapshot ccweb one) will only give you access to one branch. If you are used to working on several branches at once, you will need several views.

• all operations are file-per-file, so the idea on working on a private branch, then merge is cumbersome because of the number of merges involved.
  I strongly recommend working on a common branch for a given development effort that several developers want to address.
  If they want private branches and sandbox, they can setup a Git view within their ClearCase view without problem.
  (Note: a snapshot view cannot be considered as a sandbox: when you check-in a file, every other developer will see your changes when they will do an update of their snapshot view)

• the ClearCase Eclipse plugin does support refactoring.

• the notion of svn:external is not really supported in ClearCase, except through links. Or through UCM baseline dependencies.
  One should be aware that it is easier to work with binaries dependencies than with sources dependencies: if your external is for including the thousand of source files of the next project, it will be cumbersome in ClearCase (due to long updates). If you include a few jar or dll, that is much quicker (plus those are the one which will actually be deployed).

• If you are working with UCM, it will not be possible to move codes from one component to another. You will have to clearfsimport the main labels in the new identified "common" component.

• Note: RCS keyword substitution is generally considered... evil ;) I would recommend a separate text file with the version or labels of relevant important files in it. That works fine for delivery materials, not for source files.

这篇关于ClearCase是否适合我们的开发流程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！