需要有关发布管理策略的建议或指示

Question

我负责维护一个持续使用 (24/5) 的基于 Web（Java、JSP、Mediasurface 等）的内部系统。

用户提出改进、错误修复和其他业务更改的请求。这些问题单独签署并分配给三到四个开发人员之一。

一旦问题完成，它就会被构建并且代码只提交给 SVN。然后将更改的文件（模板、html、类、jsp）复制到开发服务器并提交到不同的存储库，从那里将它们检出到 UAT 服务器进行测试。 （这通常需要重新启动 Tomcat 服务，有时还需要重新启动 Mediasurface 服务。

然后用户测试并拒绝或批准发布。如果获得批准，则将编辑的文件签出到 Live 服务器，并执行与 UAT 相同的过程。

如果被拒绝，开发者进行相关更改并重新开始发布过程。

这一切都是手动完成的，没有太多控制。在不同的开发人员处理类似文件的情况下，更改有时会被不同步代码上的构建覆盖，而在其他情况下，UAT 中的更改会因为它们混合在与已签署版本相关的文件中而被错误地移动。

我想将此转移到一个更可控和自动化的过程中，其中所有源代码和输出文件都保存在 SVN 中，并发布到由 CI 系统管理的 Dev、UAT 和 Live（我们的 .NET 内部有 TeamCity应用程序）。

我的问题是如何管理多个更改的发布，其中一些将被签署并继续进行，而另一些则被拒绝并返回给开发人员。更改可能在重叠文件上，并且简单地将每个版本合并到 发布分支 意味着必须将被拒绝的更改从分支中撤出。

有没有办法使用 SVN 和 CI 来管理这个，或者我只需要使用当前系统。

Answer 1

在我看来，回滚推送到 Release 分支的更改在我看来是您的正常做法，我认为这可能不合适。

我觉得有点奇怪的是，为什么用户会测试更改然后拒绝或批准发布？恕我直言，测试更改并确保它修复用户提出的问题应该是测试团队的任务。用户不是测试人员。如果有一个测试团队，您可以拥有一个 Testing（例如）分支，将修复/更改推送到该分支，并且测试团队使用该分支来测试和限定更改。一旦测试团队对更改进行了验证，您就可以将更改推送到发布分支（例如）并从那里进行部署。即使采用这种方法，用户也有可能会发现所做的更改存在问题，但在测试团队进行内部测试的情况下，回滚的需求将成为例外而不是常态。

Answer 2

我正在考虑功能分支，而不是我会尝试使用 Subversion 的东西。

基本上，您为每个问题创建一个分支。您可以构建、部署此分支并由用户或测试人员进行测试。如果修复不被接受，您可以继续改进分支上的修复。

如果修复确实被接受，您仍然需要将其与任何其他修复或待定更改集成，然后才能真正以任何形状或形式发布它。 您可以在这里走两条路线，您可以在当前生产的版本上集成修复以创建“维护版本”，或者您可以将“修复分支”与主线/主干合并，使其与任何内容一起发布下一个版本的主干。 在使用维护版本时，您需要格外小心，并记住在接受或从测试人员那里得到确认后的某个时间点将更改合并到主干。如果没有，您可能会在稍后发布主干时再次出现错误。

所有形式的集成都可能需要进一步测试；孤立地进行修复可能还可以，但在与系统的所有最新更改集成时可能表现不佳。如果集成涉及合并等，那里也可能存在错误。 考虑到这一点，我会坚持谈判发布。测试人员应该测试版本，而不是孤立地测试单个修复。

发现和解决问题并不总是意味着必须立即部署。有时您可以与客户协商； “如果我们将这个错误修复与我们的下一个常规版本一起发布，可以吗？”。

机会、热修复和带外发布的整个簿记和管理很快就会变得过于复杂，我会尽可能避免。如果你有 4 个修复，其中 1 个还不行，而其他 3 个可以等待......走那条路。

Answer 3

我们决定采用多流方法。基本上，每个开发人员都在为每个更改创建一个新分支，并且在准备好更改后将其合并到 Dev 流中，TeamCity 会监视这一点，并将构建的应用程序发布到 Dev 服务器以进行集成测试。

如果通过了，则将从原始分支合并到 UAT 流中的更改。再次由 TC 发布到 UAT 服务器。

一旦签署，更改就会再次从原始分支合并到实时流中，TC 会将其发布到实时服务器。

需要注意的是，相关流必须在每次发布之前合并到分支中，以便开发人员进行测试。

这是一个有点冗长的过程，但由于我们对于测试部门来说太小了，在我能够说服企业考虑 sprint 或其他一些定期/打包的发布过程之前，我们将不得不忍受它。

非常感谢以上所有 cmets 和建议。