3

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

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

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

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

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

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

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

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

4

1 回答 1

1

The rule of thumb is simple:
The less branch, the better.

I mean, if you ever done deliver and rebase before with ClearCase, you know:

  • how painful it is
  • how poorly it scales with the number of file (merging 1000 files is awfully long, merging 5000 files is murder)

So the real rule of thumb is:

if you don't have to modify any file for a given development stage, don't create a branch.

For instance, for promoting a code to QA, where you will only read it (and launch some tests, in order to accept that code if they pass, or to reject that code if they fail), don't create a QA Stream where you would deliver the code: it is too long for an non-existent added value.

Use baseline promotion level whenever you can, and recommend your promoted baselines.

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.

Err... no, if you don't have any change to do.
The Deployment Engineer doesn't care at all where the baseline is coming from, only if the code deploys and runs successfully.

于 2012-04-07T21:34:52.983 回答