Question

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

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

我们有一个分支机构，并从分支机构取得了现场分支机构。现场分支代表主要版本，每三个月发布一次。

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

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

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

我不是做构建的人，所以我希望找到一个直接的管理方法，因为它会让我更容易让构建经理对采用它感兴趣。

Answer 1

我认为您需要的是更改存储库布局。如果我理解正确，您的存储库看起来像这样：

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

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

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

每个时间单位提交的代码行数。您不能/不希望全局更改它，因为它是开发人员的生产力输出。
测试覆盖率，也就是说，实际执行代码的频率以及涉及的代码库量。通过在发布之前为人们提供更多时间进行测试或通过实施自动化测试，可以轻松地进行更改。这是一个资源问题。

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

您希望增加隔离效果。

大多数版本控制系统中的隔离由

实现

每个原子提交增加修订号
分支

您可以尝试实施一个解决方案，将多个版本的更改打包到release-packages中，就像版本控制系统“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)

人们需要花更多的时间考虑将他们的更改“定位”到正确的版本，但这可能导致不那么紧急的更改（特别是在共享/库代码上）在发布版本之外停留更长时间并在实时分支内部通过偶然或系统测试，他们可以在上线之前被发现（参见因子测试报道）。当然还需要额外的合并，有时会将实时分支的变化分解为日常分支。

现在请不要带我太过文化与日常分支。在我的公司，我们有2周的迭代次数，并且每次迭代都有一个发布分支，并且它已经足以支持维护该分支。

而不是按天隔离，您可以尝试按产品/网站隔离。

项目分支

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个月太长了，无法轻松整合。

第三种方法是最极端的。

项目＆amp;迭代分支

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

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

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

应用来源控制有很多关于风险控制以提高产品质量。

虽然决定公司希望提供的质量水平可能不在您的手中，但知道这将有助于您决定建议的更改。可能会让您的客户对您的质量充满满意，并进一步努力增加它不会摊销。

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

1 个答案: