更好的发布管理策略？

Question

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

Trunk是生产服务器上始终存在的内容在任何给定时间都有2个分支机构1)维护版本.这是每周三发布的2)Sprint分支.这是每周发布的(周三与那个星期的maint分支)

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

我发现在运行svn merge时,它通常会在合并时产生大量问题.因此,我们每周一次切换到一次手动合并会议,这需要10分钟到1小时,在这里,我确实将我的系统中的两个目录组合在一起并询问每个开发人员"这是您的更改吗？我们应该使用哪个版本的代码保持？"

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

有人能提出更好的建议吗？

Answer 1

您的主干分支应包含所有最新的开发代码,其中包括新的和未经测试的功能以及来自其他分支的任何代码.这是非常重要的,所有的代码被合并到该分支.

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

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

分支层次结构如下所示:

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

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

Answer 2

首先，对不起！我不羡慕你的地位。

我曾在一家国际银行工作，为《联邦卡法案》进行网页重新设计。和你的情况一样，只是规模可能大得多。我们有 3 个人除了按照非常相似的时间表进行发布管理之外什么也不做。使它可行的事情（在几周内我一次处理了几百个文件）是开发人员合并到主干，然后主干作为副本部署到生产环境......我们没有直接检查进入生产。因此，从发布的角度来看，您可能正在帮助开发人员签入他们的工作（进行“更新”或回答“这是正确的版本吗？”真的有什么区别）但是您并不是盲目地选择哪个更新应该上线，这似乎是一个大问题。当然，开发人员可能会抱怨一点，但处于这个位置确实还不错。如果您愿意回答可能出现的任何问题，应该没问题。它适用于我们在全国 4 个地点工作的 1,200 多名开发人员。

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