如何管理具有多个重叠更改和每日重建的源代码控制更改集？

Question

我在一家使用 cvs 进行版本控制的公司工作。

我们开发和维护一个包含大约一百个可执行文件的在线系统 - 它们共享大量代码和大量支持文件。

我们有一个主枝，以及从主枝上取下的活枝。实时分支代表大约每三个月发布一次的主要版本。

此外，还有许多日常错误修复必须应用于实时分支 - 因此它们可以立即转移到实时环境，并合并回头分支，因此它们将出现在下一个主要版本中。

我们最明显的困难是日常修复。由于我们每天都有很多修改，测试环境总是会发生多次变化。通常，当为一项任务重新构建可执行文件时，对共享代码的未经测试的更改会包含在构建中并带到实时环境中。

在我看来，我们需要一些工具来更好地管理变更集。

我不是负责构建的人，所以我希望找到一个直接的流程来管理它，因为这将使我更容易让构建经理有兴趣采用它。

Answer 1

我认为您需要的是存储库布局的更改。如果我理解正确，您的存储库如下所示：

Mainline
|
 -- Live branch January (v 1.0)
|
 -- Live branch April  (v 2.0)
|
 -- Live branch July  (v 3.0)

因此每个分支都包含您的所有站点（数百个）以及共享代码的文件夹。

没有科学的方法可以准确地告诉发布后出现错误的可能性，但让我们看一下两个最重要的因素：

• 每个时间单位提交的代码行数。您不能/不想全局更改它，因为它是开发人员的生产力输出。
• 测试覆盖率，又名在上线之前执行代码的频率以及涉及的代码库的数量。通过在发布前给予人们更多时间进行测试或实施自动化测试，可以轻松改变这种情况。这是一个资源问题。

如果您的公司既不想花钱进行额外的测试，也不想降低发布频率（不一定是生产力！），那么您确实必须找到一种方法来发布更少的更改，从而有效地减少每个版本更改的代码行数。
基于这种洞察，让所有开发人员都提交到同一个分支并每天多次从那里上线听起来不是一个好主意，不是吗？

您想要增加隔离。

大多数版本控制系统中的隔离是通过

1. 增加每个原子提交的修订号
2. 来

实现的。 分支 您可以尝试实现一个解决方案，将多个修订的更改打包到发布包中，有点像版本控制系统“perforce”所做的那样。但我不会这样做，因为分支总是更容易。牢记 KISS 原则。

那么分支有什么帮助呢？
您可以尝试将今天必须上线的变更与可能明天或下周上线的变更分开。

迭代分支

Mainline
|
 -- Live branch July  (v 3.0)
    |
     -- Monday (may result in releases 3.0.1 - 3.0.5)
    |
     -- Thuesday (may result in releases 3.0.6 - 3.0.8)
    |
     -- Wednesday (may result in releases 3.0.9 - 3.0.14)

人们需要花更多的时间考虑将他们的更改“定位”到正确的版本，但这可能会导致不那么紧急的更改（特别是共享/库代码）在版本之外停留更长时间在上线分支内部，可以在上线之前通过偶然或系统测试发现它们（请参阅因素测试覆盖率）。
当然，需要进行额外的合并，有时会将实时分支中的更改挑选到每日分支中。

现在请不要太从字面上理解我的每日分支。在我的公司，我们有两周的迭代，每个迭代都有一个发布分支，并且已经有足够的开销来维护该分支。

您可以尝试按产品/站点进行隔离，而不是按白天进行隔离。

项目分支

Mainline
    |
     -- Live branch July  (v 3.0)
        |
         -- Mysite-A (released when something in A changed and only released to the destination of A)
        |
         -- Mysite-B
        |
         -- Mysite-C

在这种情况下，单个站点的代码以及所有需要的共享代码和库将驻留在这样的站点分支中。
如果必须更改共享代码才能在站点 A 中工作，您只需更改站点 A 中的共享代码。您还可以合并更改，以便任何人都可以赶上您的更改。追赶周期可能比发布周期长很多，因此代码有时间“成熟”。
当然，在部署/构建过程中，您必须确保站点 A 的共享代码不会覆盖站点 B 使用的共享代码。您正在有效地“分叉”具有所有含义的共享代码（不兼容性、集成团队变更的开销）。

偶尔应该强制合并到实时分支（您可能也想重命名它）以集成对共享代码所做的所有更改。我猜你的 3 个月迭代会迫使你这样做，但你可能会发现 3 个月对于无麻烦的集成来说太长了。

第三种方法是最极端的。

项目与迭代分支

Mainline
    |
     -- Live branch July  (v 3.0)
        |
         -- Mysite-A 
            |
            -- Week 1
            |
            -- Week 2
            |
            -- Week 3
        |
         -- Mysite-B
            |
            -- Week 1
            |
            -- Week 2
            |
            -- Week 3
        |
         -- Mysite-C
            |
            -- Week 1
            |
            -- Week 2
            |
            -- Week 3

如果您不注意的话，这肯定会带来大量的开销和潜在的麻烦。从好的方面来说，您可以非常准确地仅部署此项目/站点现在所需的更改。

我希望这一切能给你一些想法。

应用源代码控制主要涉及风险控制，以提高产品质量。

虽然您的公司想要提供何种质量水平的决定权可能不在您手中，但了解这一点将帮助您决定建议哪些更改。可能结果是您的客户对您的质量非常满意，并且进一步努力提高质量并不会摊销。

祝你好运。
克里斯托夫