交付机制，Rational ClearCase

我们想出了Rational ClearCase UCM模型的流结构。交付机制，Rational ClearCase

Int 
-- Prd 
-- Uat 
-- Dev 
---- Development Stream r1.0

我们最近将代码库迁移到了新的设置中。我们有三个不同的代码库，即三个物理代码库。

迁移过程：

我们首先提出的生产代码，创建了一个活动，交付活动Integration流，创造了一个基线。
然后，uat代码创建一个活动，将活动交付给集成流，在合并期间，我们选择了来自贡献者2的更改以保留来自uat的现有代码，创建了基线。开发环境的相同过程。

截止目前，整合流具有最新的基线，即开发基线。
现在我们还有其他两个流，分别用于prd和uat，这些流将在相应的环境中发布。

我现在有我的开发流。我创建一个活动并进行一些更改。现在我需要将这些改变推广到uat环境中。如果我将更改传递到集成流，则合并完成，但在开发基线上。我不想将其重新分配给uat，因为许多开发应用程序将被重新发布到不希望的uat中。

我该如何实现促进对uat环境（uat流）的更改。友善的建议。

来源

2010-04-08 kadaba

看起来你流结构是这样的：

Int 
    Dev 
    UAT 
    Prd

如果我提交所做的更改集成流，合并完成后，但在发展basline。我不想将其重新分配给uat，因为许多开发应用程序将被重新发布到不希望的uat中。

流的原理是隔离特定的开发工作：

日常开发的开发
试验以只读模式UAT（你不应该碰任何东西，只是在PRD测试并接受或拒绝）
热修复

诠释为吨这里记录最新的Prd基线，以便允许另一个项目使用这些基线中的一个作为起点，避免使用从分支分支（“级联分支”）制作的基线。

我会建议（而这仅仅是一个命题，许多其他结构是可能的，取决于具体的设置，你需要隔离一个来自另一个开发力度）：

Int 
    Prd 
    Dev 
    UAT

你变基UAT无论您想要测试的Dev基线如何，Dev都可以进行日常开发，而不会混淆正在测试的用户验收测试内容
如果基准重新升级为UAT符合预期，则直接将其交付给prod （可能会出现一些最后一分钟的修补程序）
当Prd基线设置稳定时，您将其交付给Int（以记录这是在生产中运行的事实

来源

2010-04-08 06:22:55 VonC

Von，感谢您的回复。恐怕我明白这一点。我现在会邮寄给你。请看看它。 – kadaba 2010-04-08 07:00:41

@ kabada：这一切都取决于你想在这些不同的流中做什么。但是为了澄清这个问题，发布你当前的流结构（通过更新你的SO问题）将是一个好的开始。 – VonC 2010-04-08 07:12:41

我已邮寄给你，也有更新内容。 “Int在那里记录最新的Prd基线” - 现在这就是我所关心的。因为我在不同的环境中处理不同的发布流。到目前为止，我在prd中只有几个应用程序，在uat中只有很少的应用程序，并且正在开发中。我认为整合流是一个共同的合并点（即所有交付都会发生在开发流的整合流中）。这种方法对单个版本的代码来说看起来很合理，但我们已经有三种，因此遇到了这种传递机制的问题。 – kadaba 2010-04-08 08:43:50

交付机制，Rational ClearCase

回答

相关问题