需要关于发布管理策略的建议或指导

Question

我关注一直在使用（24/5）的内部基于Web的（Java，JSP，Mediasurface等）系统。

用户提高增强功能，错误修复和其他业务更改的门票。这些问题将单独签署并分配给三个或四个开发人员中的一个。

一旦问题完成，它就会生成并且代码只能提交给SVN。然后，将更改后的文件（模板，html，类，jsp）复制到开发服务器并提交到不同的存储库，从它们签出到UAT服务器的位置进行测试。 （这通常需要重启Tomcat服务，偶尔也需要Mediasurface服务）。

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

如果被拒绝，开发人员会进行相关更改并再次启动发布过程。

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

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

我的问题是如何管理多个更改的发布，其中一些将被签名并移动，其他人将被拒绝并返回给开发人员。这些更改可能在重叠文件上，并将每个版本简单合并到版本分支意味着被拒绝的更改将不得不从分支中退出。

有没有一种方法可以使用SVN和CI来管理这个问题，还是我只需要使用当前的系统。

Answer 1

在我看来，回滚推送到版本分支的更改在我看来似乎是您的案例中的一种常规做法，我认为这可能不合适。

我觉得有一点令人惊讶的是，为什么用户会测试更改，然后拒绝或批准发布？恕我直言，对这些变化进行测试并确保它能够修复用户提出的问题应该是测试团队的任务。用户不是测试人员。如果有测试团队，您可以有一个测试（比如说）分支，其中修复/更改被推送到，并且测试团队使用该分支来测试和限定更改。一旦这些更改得到测试团队的认可，您可以将更改推送到发布分支（比如说），然后从那里进行部署。即使采用这种方法，用户也会有机会发现所做更改的问题，但随着测试团队在进行内部测试时，回滚需求将成为一种例外而非标准。

Answer 2

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

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

如果修复程序确实被接受，您仍然需要将它与任何其他修复程序或待处理的更改集成，然后才能真正释放它的任何形状或形式。 您可以在这里找到两条路线，您可以在当前正在生产的版本上集成修订以创建“维护版本”，或者您可以将“修复分支”与mainline/trunk合并，以便与其一起发布无论下一次释放干线。 使用维护版本时，您需要格外谨慎，并且记得在验收后的某个时间点将变更合并到主干，或者在测试人员已经完成后将其合并。如果不是这种情况，当后备干线获得释放时，可能会再次发生错误。

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

查找和解决问题并不总是意味着它必须立即部署。有时你可以和你的顾客谈判; “如果我们将这个错误修复与我们的下一个正式版本一起发布，是否可以？”。

机会，热修复和带外发布的整个簿记和管理非常迅速地过度复杂，我会尽可能避免它。如果你有4个修补程序，1个还不行，另外3个可以等待......去那条路线。

Answer 3

我们决定采用多流方式。基本上，每个开发人员都会为每个更改工作一个新分支，准备就绪时将更改合并到Dev流中，TeamCity会监视此情况，并将应用程序构建并发布到Dev服务器以进行集成测试。

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

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

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

这是一个抽出的过程，但由于我们对于测试部门来说太小了，直到我能说服业务考虑冲刺或其他定期/打包的发布过程，我们将不得不忍受它。

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