我负责持续使用的内部基于Web（Java，JSP，Mediasurface等）的系统（24/5）。
用户提出增强功能，错误修复和其他业务更改的门票。这些问题单独签署并分配给三个或四个开发人员中的一个。
一旦问题完成，它就会构建，代码只会提交给SVN。然后将更改的文件（模板，html，类，jsp）复制到开发服务器并提交到不同的存储库，从这些存储库检出它们到UAT服务器进行测试。 （这通常需要重新启动Tomcat服务，有时也需要Mediasurface服务。）
用户然后测试并拒绝或批准发布。如果批准，则编辑的文件将签出到实时服务器，并且与UAT执行的过程相同。
如果被拒绝，开发人员会进行相关更改并再次启动发布过程。
这一切都是手动完成的，没有太多控制。在不同的开发人员正在处理类似文件的情况下，更改有时会被不同步代码上的构建所覆盖，在其他情况下，UAT中的更改会因为与已签名的版本相关联的文件混淆而移动到错误中。
我想将其转移到一个更加受控制的自动化流程，其中所有源代码和输出文件都保存在SVN中，并发布到由CI系统管理的Dev，UAT和Live（我们的.NET内部有TeamCity）应用）。
我的问题是如何管理多个更改的发布，其中一些将被签署并移动，其他人被拒绝并返回给开发人员。更改可能在重叠文件上，只需将每个版本合并到发布分支即表示拒绝的更改必须从分支中退出。
有没有办法使用SVN和CI来管理它，或者我只需要使用当前系统。
答案 0 :(得分：1)
在我看来，回滚推送到 Release 分支的更改在我看来是正常的做法，我认为这可能不合适。
我觉得有点令人惊讶的一件事是，为什么用户会测试更改，然后拒绝或批准发布？恕我直言测试变更并确保修复用户提出的问题应该是测试团队的任务。用户不是测试人员。如果有测试团队，您可以使用测试（例如）分支来修改/更改，并且测试团队使用该分支进行测试并验证更改。一旦测试团队对更改进行了限定，您就可以将更改推送到发布分支（比如说）并从那里进行部署。即使采用这种方法，用户也有机会发现所做更改的问题，但是在测试团队进行内部测试时，回滚的需求将成为例外，而不是常态。
答案 1 :(得分：0)
我正在考虑功能分支，而不是我尝试使用Subversion。
基本上，您为每个问题创建一个分支。您可以构建，部署并经过用户或测试人员测试的此分支。如果未接受此修复程序，您可以继续改进分支上的修复程序。
如果修复程序已被接受，您仍需要将其与任何其他修补程序或待定更改集成，然后才能真正释放它的任何形状或形式。 您可以在这里使用两条路线，您可以将修复程序集成到当前正在生产的版本中以创建“维护版本”，或者您可以将“修复分支”与主线/主干合并，以便与任何内容一起发布下一个版本的主干。 使用维护版本时，您需要格外小心，并记住在接受或从测试人员那里得到确定后，在某些时候将更改合并到主干。如果不是，您可能会在以后释放后备箱时遇到重新出现的错误。
所有形式的整合都可能需要进一步测试;修复可能是孤立的，但在与系统的所有最新更改集成时可能执行得不太好。如果涉及的集成合并，那么也可能存在错误。 考虑到这一点，我会坚持谈判发布。测试人员应该测试版本，而不是单独测试。
查找并修复问题并不总是意味着必须立即部署。有时你可以与你的客户谈判; “如果我们将这个错误修复与我们的下一个常规版本一起发布，那可以吗？”。
整个记账和管理机会，热修复和带外版本变得非常复杂，我会尽可能地避免它。如果你有4个修正，1个还不行，其他3个可以等待......去那个路线。
答案 2 :(得分：0)
我们决定采用多流方式。基本上每个开发人员在每个更改的新分支上工作，当准备好将更改合并到Dev流中时，TeamCity会监视这个，并且构建应用程序并将其发布到Dev服务器以进行集成测试。
如果通过，则更改将从原始分支合并到UAT流。 TC再次将其发布到UAT服务器。
一旦注销，更改将再次从原始分支合并到实时流中，TC将其发布到实时服务器。
应该注意的是，必须在每次发布之前将相关流合并到分支中，以允许开发人员进行测试。
这是一个抽象的过程，但由于我们对测试部门来说很小，直到我能说服企业考虑冲刺或其他一些定期/打包的发布过程，我们将不得不忍受它。 / p>
非常感谢上述所有意见和建议。