更好的发布管理策略？

Question

我为一家制作基于网络的工具的公司工作。作为我工作的一部分，我被赋予了该产品的发布工程任务（我之前从未做过的事情）。我使用SVN设置了以下系统（对不起，在有人建议切换到GIT或perforce或其他众多选项之一之前，我们不能使用其他存储库！）

Trunk是生产服务器上始终存在的东西 在任何给定时间都有2个分支机构开放 1）维护发布。这是每周三发布的 2）Sprint分支。这是每周发布的（周三与那个星期的maint分支）

在发布之前，我将那些周分支合并到主干中。

我发现在运行svn merge时，它通常会在合并时产生大量问题。因此，我们每周一次切换到一次手动合并会议，这需要10分钟到1小时，在那里我真正地在我的系统上汇集2个目录并且询问每个开发人员“这是您的更改吗？我们应该使用哪个版本的代码保持？“

这个系统绝对不是理想的。

有人可以提出更好的建议吗？

Answer 1

您的 trunk 分支应包含所有最新的开发代码，其中包括新的和未经测试的功能以及来自其他分支的任何代码。 非常重要的是所有代码都合并到这个分支中。

当您准备好（或认为已准备好）进行测试时，请从主干分支创建稳定分支。使用此分支仅测试和修复错误。不要在此处为​​您的应用程序添加任何新功能或改进，否则可能会破坏您现有代码的稳定性。不要忘记将此分支中所做的更改合并到主干分支中。

当您准备发布（测试已完成）时，请从稳定分支创建发布分支。如果在生产中发现错误/问题，这是您发布到生产和维护/支持的分支。与稳定分支一样，不要向此分支添加任何新内容。通常标记此分支以便在生产中识别它。不要忘记将此分支中所做的更改合并到稳定分支中，以便从稳定分支创建的其他发布分支可以获得任何错误修复的好处。

分支层次结构如下所示：

trunk
|-- stable 1.0
  |-- release 1.0
  |-- release 1.1
|-- stable 2.0
  |-- release 2.0

使用此层次结构，您的开发团队可以在主干分支中自由开发，而稳定和发布分支允许维护应用程序的当前版本和先前版本。

Answer 2

声明“在任何给定时间有2个分支开放”对我来说很麻烦。至少在我的实践中，分支是在发布之前为了稳定而创建的，或者用于修复bug，它们通常是短暂的。

我的问题是 - 你用什么干线？它不应该是生产中的东西，而是生产应该运行标记（因此发布）版本。

据我所知，你的合并问题是自我造成的。

Answer 3

首先，抱歉！我不羡慕你的立场。

我曾在一家国际银行为“联邦卡法”进行网络重新设计。与您相同的情况，仅可能在更大的范围内。我们有3个人除了按照非常类似的时间表发布管理外什么都没做。使它成为可能的事情（在几周内我一次只处理了几百个文件）是开发人员合并到trunk，然后trunk作为副本部署到生产的事实....我们没有直接检查生产。因此，从发布的角度来看，您可能正在帮助畜栏开发人员检查他们的工作（做“更新”或回答“这是正确的版本吗？”之间的区别是什么？）但是那时你不是盲目地选择哪个更新应该上线，这似乎是一个主要问题。当然，开发人员可能会抱怨一下，但是一直处于这个位置并不是太糟糕。如果你让自己可以回答任何可能出现的问题，那就应该没问题。它适用于我们在全国4个地点工作的1,200多名开发人员。

这给你买的另一件事是时间来测试。如果代码在上线之前没有合并，那么如何在更大的系统环境中对其进行测试呢？我当然希望答案不是它没有经过测试！

Answer 4

此方案的理想分支策略是。在主干和每个版本中的最新开发削减了一个分支，称之为维护发布分支。但是在您的情况下，维护释放发生在主干中。最新的发展发生在分支机构。

将分支策略放在一边。以下是一些改善现状的建议。

1. 正如你所说，生产相关的变化首先发生在主干，我认为它会是最小的。那么，为什么不经常将每个与生产相关的变更合并到这些其他开放分支机构中。我会说每天一次，它也可能更频繁或更不频繁。你将能够更好地判断。这也可以让开发人员更好地了解生产中发生的变化，减少冲突。此外，如果存在冲突，这将由开发人员自己在分支机构处理。

2. 您可以考虑提出某种框架

   • 应该能够定义哪些分支需要在trunk中进行提交。

   • 可以有一个post commit钩子脚本，它将检查提交是否在trunk中并立即与分支进行svn合并，看看它们是否存在冲突。

   • 如果合并成功，则提交更改。否则将信息邮寄给您和提交它的相应开发人员（这取决于您希望如何处理此问题）。