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

Question

我负责一个基于 Web(Java、JSP、Mediasurface 等)的内部系统，该系统一直在使用 (24/5)。

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

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

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

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

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

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

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

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

Answer 1

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

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