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

Question

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

此开发工作产生了许多候选版本，其中某个版本可以被提名在开发过程中向上移动直到它到达生产，同样，在某些情况下，生产中部署的代码可能需要热修复与当前的内部开发线（即并行开发）平行。

对于由IBM Rational ClearCase（CC）维护的某个UCM项目，在“Project Explorer”上创建的建议项目结构是什么，以适应以下内容：

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

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

我向所有人道歉，因为我明白回答这个问题的时间可能很长，但我的问题更多地集中在需要在“Project Explorer”中创建的流和/或视图的确切类型，以满足上述目标。 / p>

我真的想尝试使用CC进行版本管理的最佳实践方法，以及如何最好地将其用于此目的。

我将非常感谢你的帮助，并且非常感谢所有提前...

Answer 1

经验法则很简单：
分支越少越好。

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

• 多么痛苦
• 它与文件数量的关系有多差（合并1000个文件非常长，合并5000个文件就是谋杀）

所以真正的经验法则是：

如果您不必修改特定开发阶段的任何文件，请不要创建分支。

例如，要将代码提升为QA，您只能阅读它（并启动一些测试，以便在代码通过时接受该代码，或者如果代码失败则拒绝该代码）， don＆＃ 39;创建一个QA流，您可以在其中传递代码：对于不存在的附加值，它太长了。

尽可能使用 baseline promotion level 和recommend your promoted baselines。

  

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

呃...不，如果你没有做任何改变。
只有在代码部署并成功运行的情况下，部署工程师并不关心基线的来源。