典型的ClearCase最佳实践项目结构

Question

在开发项目中，交付的代码可能会在达到生产环境之前在不同阶段的不同环境中进行切换（例如，开发环境用于测试部署过程，内部测试用于质量控制，预生产环境最终达到生产环境）。

这个开发过程会产生许多候选发布版本，其中某个版本可以被提名向上移动到开发流程中，直到达到生产环境。此外，有些情况下，部署在生产环境上的代码可能需要与当前内部开发线路（即并行开发）平行修复。

对于由IBM Rational ClearCase（CC）维护的某个UCM项目，应该在“项目资源管理器”上创建什么样的推荐项目结构，以适应以下情况：

1. 开发人员应主要连接并交付他们的工作到内部开发线路（或在CC术语中称为开发流）。 2. 一旦认为已将交付到该开发流的代码接受，技术团队领导（TTL）可以创建一个基线。稍后，部署工程师可以检索此基线以便在本地开发环境中部署。 3. 如果发现此基线可接受，则可以将其整体交付给内部测试流以进行进一步的质量控制（QC）测试。 4. 如果发现此基线可接受，则可以将其整体交付给预生产环境等，以达到与上述类似的生产环境。 5. 当然，如果这些基线中的任何一个被其接收方拒绝，它可以被拒绝，接收方将等待推荐其流的另一个基线。

请注意：部署工程师将始终为每个环境使用专用流来获取所需的文件以执行构建/部署活动。

对于此问题的回答可能会很长，我向大家道歉。但是我的问题更集中于需要在“项目资源管理器”中创建哪种类型的流和/或视图才能满足上述目标。

我真的在尝试制定使用CC进行发布管理的最佳实践方法，以及如何最好地用于此目的。

感谢你们的帮助，提前感谢所有人...

- yazankhs

Answer 1

经验之谈：

分支越少，越好。

我的意思是，如果您以前使用过ClearCase进行过交付和变基，那么您就会知道：

• 它有多痛苦
• 它在文件数量上缩放得很差（合并1000个文件非常漫长，合并5000个文件更麻烦）

因此真正的经验之谈是：

如果在给定的开发阶段中不必修改任何文件，则不要创建分支。

例如，将代码推广到QA时，您仅需要读取它（并启动一些测试，以接受通过测试的代码或拒绝未通过测试的代码），不要创建QA Stream来交付代码：这对于不存在添加值而言太长了。

尽可能使用基准促销级别，并推荐您的促销基线。

部署工程师将始终为每个环境使用专用流来获取所需的文件以执行构建/部署活动。

嗯...不，如果您没有任何更改要进行。 部署工程师完全不关心基线来自哪里，只关心代码是否成功部署和运行。

- VonC