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

Question

在开发项目期间，交付的代码可以在到达生产之前在不同环境的不同阶段之间移动(例如，用于测试部署过程的开发环境、用于 QC 的内部测试、预生产和最终生产)。

这种开发工作产生了许多候选版本，其中可以指定某个版本在开发过程中向上移动，直到它到达生产环境，此外，在某些情况下，部署在生产环境中的代码可能需要与当前的内部开发线(即并行开发)。

对于 IBM Rational ClearCase (CC) 维护的某个 UCM 项目，建议在“项目资源管理器”上创建什么项目结构以适应以下内容:

开发人员应主要在内部开发线(或 CC 术语中的开发流)上连接和交付他们的工作。

一旦交付给这个开发流的代码被认为是可接受的，技术团队负责人 (TTL) 就可以创建一个基线。该基线可以稍后由部署工程师检索以部署在本地开发环境中。

如果发现此基线是可接受的，则可以将该基线作为一个整体交付给内部测试流，以部署用于进一步的质量控制 (QC) 测试。

如果发现该基线是可接受的，则可以将该基线作为一个整体交付给预生产，以此类推，类似于上面描述的那样交付给生产。

当然，如果这些基线中的任何一个没有被其接收方接受，它可以被拒绝，并且接收方将等待另一个基线被推荐用于他们的流。

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

我对这里的每个人表示歉意，因为我知道回答这个问题可能会很长，但我的问题更多地集中在需要在“项目资源管理器”中创建以满足上述目标的流和/或 View 的确切类型。

我真的想提出使用 CC 进行发布管理的最佳实践方法，以及如何最好地使用它。

我将感谢您的帮助，并在此先感谢所有人...

Answer 1

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

我的意思是，如果你之前使用 ClearCase 完成过交付和 rebase ，你就会知道:

有多痛

它与文件数量的缩放比例有多差(合并 1000 个文件非常长，合并 5000 个文件是谋杀)

所以真正的经验法则是:

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

例如，为了将代码提升到 QA，您只会阅读它(并启动一些测试，以便在它们通过时接受该代码，或者如果它们失败则拒绝该代码)， 不要创建一个 QA Stream 来传递代码 : 对于一个不存在的附加值来说太长了。

使用 baseline promotion level 只要有可能， recommend your promoted baselines .

The Deployment Engineer will always use a dedicated stream for each environment to get his/her files required to carry out the build/deployment activities.

呃……不，如果你没有任何改变要做的话。
部署工程师根本不关心基线来自哪里，只要代码部署并成功运行即可。