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

Question

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

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

我们有一个头部分支，并从头部分支采取活枝。现场分支代表每三个月发布的主要版本。

此外，还有很多每日错误修复，必须应用于两个活分支 - 因此他们可以带到实况环境immeadiatley，并合并回头分支，所以他们将在下一个主要发布。

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

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

我不是谁做的构建者，所以我希望能找到一个直接的过程来管理这一点，因为这将让我更容易获得兴趣采用它构建管理。

Answer 1

我认为你需要的是一个存储库布局的改变。如果我理解正确的话，你的资料库看起来是这样的：

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

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

没有科学的方法来确切地告诉释放之后出现错误的机会，但让我们看看最重要的两个因素：

• 行代码每时间单元COMMITED数。由于它是开发人员的生产力输出，因此您不能/不会希望全局更改此内容。
• 测试覆盖，又名多久被代码之前beeing生活和如何你的代码中有多少涉及执行。通过在发布之前给用户更多的时间进行测试或者通过实施自动化测试，可以很容易地改变这一点它是一个资源问题。

如果你的公司都不希望把钱花在额外的测试，也没有减少释放频率（不neccessarily生产力！），你确实必须找到一种方式来释放更少的变化，effecively减少改变行代码每数量发布。 由于这种认识的结果，让所有开发者提交到同一分支，从每天有多次去住听起来不像是个好主意，不是吗？

您希望增加隔离。

在大多数版本控制研究系统隔离是通过每个原子

1. 递增版本号来实现承诺
2. 分支

你可以尝试实现一个包从多个版本到版本变化的解决方案-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个月的时间太长，无法进行无障碍整合。

第三种方法是最极端的。

项目&迭代分行

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 

这无疑带来了开销和潜在的头痛，如果你不重视的一个巨大的ammount的。在好的一面，你可以非常准确地部署所需的变化现在为这个项目/网站。

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

应用来源控制对于增加产品质量的风险控制很有帮助。

虽然决定您的公司想要交付的质量水平可能不在您的手中，但知道这将有助于您决定要进行哪些更改。可能会发现你的客户对你的质量有充分的满足，并且进一步努力增加它不会摊销。

祝你好运。 Christoph