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

时间:2012-04-07 20:48:57

标签: version-control clearcase clearcase-ucm ibm-rational

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

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

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

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

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

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

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

1 个答案:

答案 0 :(得分:1)

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

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

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

所以真正的经验法则是:

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

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

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

promoted baselines

  

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

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