3

我不幸有机会通过 Borland 的 StarTeam 进行源代码控制。不幸的是，它做得很少，一个最大的弱点是它的视图管理。我喜欢 SVN，并且来自 SVN 的心态。我们的问题是后期生产发布，我们花费无数小时将更改合并到“生产支持”环境中。

请不要骚扰我，这不是我做的，我继承了它，并试图提供一种更好的方法来管理存储库。不能切换到不同的 SCM 工具。

当前设置

  • Product.1.0（TRUNK，当前生产代码，在这个级别是待定的错误修复）
    • Product.2.0（真正的主干任何签入的东西都经过测试，然后在下一个生产周期发布，这个视图发生了很多变化）

我的建议是交换它们，在主干（生产）上完成所有开发，在发布上标记，并根据需要创建子视图来表示生产支持错误修复。

  • 生产
    • 生产.2.0.SP.1

我找不到任何文档来支持上述提议，因此我试图就更改是否是一个好主意以及是否有任何建议您建议采取不同的做法获得反馈。

4

3 回答 3

3

我使用受 Henry Kniberg 的文章Version Control for Multiple Agile Teams启发的中间方法。我在下面引用一小部分：

大图

好的，现在我已经通过一个相当详细的示例来说明如何使用此模式。现在让我们退后一步，看看大局。

在主线模型中，分支称为代码线（实际上，分支被认为是代码线的实现）。有时这些被称为流。

代码线的父代（即它源自的代码线）称为其基线。Mainline 是没有基线的代码行。

所以在我们上面的例子中，我们可以得出结论：

  • 主干是我们的主线。它没有父母吗？
  • 所有其他代码行（1.0 版，团队 A 工作，团队 B 工作）都将主干作为基线。

这是一个更复杂的例子：

替代文字
（来源：infoq.com）

这张照片告诉我们：

  • 项目 X 代码线是从主线产生的。项目现已完成，因此分支已关闭。
  • 团队 A 有一个从主线生成的活动工作分支。
  • 团队 A 也有一个从工作分支产生的持续峰值。
  • 发布 2.3 分支已关闭，因为 2.3 不再生产并且不会被维护。

每条代码线都具有相对于其基线的相对稳固性水平，即每条代码线比其基线更稳固或更不稳固（更软）。

  • 稳定的代码线是稳定的、经过全面测试的、很少更改的，并且即将发布。
  • 软代码线不稳定，几乎没有经过测试，经常更改，并且离发布还很远。

绘制代码线时，硬代码线向上分支，软代码线向下分支。所以看上图，我们可以得出结论：

  • 2.3 版比主线更坚固。
  • Team A 的工作比主线软。
  • A 队的尖峰比 A 队的工作要软。

总结一下：

  • 主干是 DONE 分支（始终可释放）
  • 工作在可能不如主干稳定的工作分支（每个团队一个）中完成
  • 发布分支是基于发布时的主干创建的。

我强烈建议阅读整篇文章。

于 2010-04-14T02:51:35.860 回答
2

这是我对构建构建流的一般建议：

+HEAD - master -> current development 
+ tags
   + version1 
   + version1.sp1 
   + version1.sp2 
   + version2
+ branches
   + version1.sp2.fixes <- at some point, this will get promoted to version1.sp3 
   + version2.fixes <- at some point, this will get promoted to version2.sp1 
   + version2.nix.feature1 <- this is your (nix's) private version2.feature branch 
   + master.nix.feature2  <- this is your (nix's) private new development feature branch.

基本上，您永远不会直接提交到 .fixes 或 master 分支——只有集成过程才能做到这一点。

无论如何，几乎所有的源代码控制工具都会支持这个模型。

于 2010-04-12T18:39:52.740 回答
2

我同意你和 Chris Kaminski 的方法。我们使用 StarTeam，这就是我们使用它的方式。每个项目中的提示或主视图是当前开发线（在 StarTeam 术语中，这是与项目名称同名的默认视图）。每当我们在此视图上进行构建时，我们的构建服务器都会创建一个构建标签。从某个构建标签开始发布。

然后，我们将在该标签上创建一个新视图作为生产发布分支，然后对该版本的任何错误修复都将应用于该视图（错误修复是否在提示视图中完成并合并到分支，反之亦然是无关紧要的，只要它们确实合并到主开发视图中）。

此外，如果我们有一个将长期运行且不会在下一个正常生产版本之前完成的特定项目，我们将使用 Branch on Change 设置从 Tip 视图分支。这绝对不是理想的，因为一旦完成就必须进行大量合并，但它确实将代码排除在主开发线之外，并确保它不会意外地出现在生产版本中。我们确实试图限制这些类型的项目，但有时业务人员会决定它们。

这种设置对我们来说效果很好，而且对于新手来说似乎很容易理解和使用。

于 2010-04-14T02:19:32.053 回答