当您对现有的业务线应用程序进行增强时，您认为将更改批量更改为不太频繁的较大版本，还是在较小的版本中不断发布新功能更好？假设有硬件升级或数据库升级，您是在版本中也进行这些更改，还是将它们分开？
将所有内容一起发布的优点是对业务的干扰更少，涉及的工作时间更少，但是您以后遇到的任何问题都可能是由于数据库升级、硬件或任何数量的软件更改造成的。
很少发布并且通常可以更容易地跟踪发布导致的任何问题，但会导致更多的中断和更多的回归测试时间。
哪个更好？
问问题
685 次
7 回答
3
考虑每个版本如何影响客户。频繁的小版本发布是否会因为更快地解决关键问题而让他们更快乐？这会提高您的销售和声誉吗？如果它会仔细估计这些好处是否超过了所做的额外工作，否则就选择对你更方便的路径。
于 2009-05-13T10:46:20.433 回答
2
这真的取决于你所处的环境。一些场景：
许多客户：您希望所有客户尽可能拥有相同的版本。每年、每半年或每季度发布一次大版本要容易得多，因为测试和推出的协调成本非常高。在这种情况下，我也会包括数据库更改。
“大型基础设施”：如果在大型公司环境中工作，并且有专门的操作系统和数据库人员，那么发布的总体成本也很高，因此不太频繁地发布较大的版本会更好。
简而言之，计算发布在人力、业务中断、协调、测试方面的成本，并将其与每个新功能或错误修复的好处联系起来。
我通常倾向于每年发布 1-2 个大版本，并在其间进行错误修复以供表演者使用。
于 2009-05-13T10:51:51.860 回答
2
我认为最好的答案是：两者兼而有之。
例如，如果您添加了一些吸引眼球的东西，或者使名称文本框更加“ajaxy”，或者可能会添加一种新型报告 - 将其设为“小”版本。尽早发布，并尽可能经常发布。
另一方面，如果您更改了面向用户的流程，迫使用户“重新培训”，或者如果您需要大规模的基础架构更改 - 进行大版本，并尽可能少地进行。
正如您所说，如果中断很少或没有中断，请尽可能多地执行，您的用户会因此而更快乐 - 而且您实际上将花费更少的时间进行回归测试，因为您只需要测试与更改相关的所有内容你做了。
于 2009-05-13T10:55:27.393 回答
1
于 2009-05-13T10:49:17.467 回答
1
我认为最好将其整合到一个大版本中并进行修补，因为您需要解决问题。
作为开发人员，您需要预测系统中可能出现的问题和中断，以使其尽可能健壮。这通常意味着事先进行大量测试。
还要考虑到最终用户可能不想为产品中较小的增量付费，他们也可能等待大更新。一个很好的例子是当我得到 Adobe Photoshop 时，他们似乎每年都会发布一个新版本，所以我只是等到看起来合适的时候
于 2009-05-13T10:50:20.037 回答
1
较少数量的版本意味着您将一次找到所有错误。很难知道哪个代码更改导致了哪个错误。然后，您在级联错误方面遇到了更多问题 - 您几个月前所做的一次代码更改导致了一个错误，但与此同时，您又进行了五次更改，这些更改都取决于您几个月前引入的错误。
较小的高质量版本更好。较小的版本更容易获得高质量。
于 2009-05-13T10:53:10.487 回答
0
事实上 - 两者兼而有之。
您可以将开发分为 DEVEL 和 RELEASE 分支吗？任何紧急问题都应尽快在 REL 分支上完成，并作为修补程序发送给用户。在将修补程序应用到 REL 分支后，应用补丁的需求将发送给 DEV 团队（注意：要修复 REL 上的一些问题，您必须编写一些快速代码，而在 DEV 分支中，您需要花一些时间重新考虑建议的修复，因为 DEV 分支中的条件可能已经改变，所以通常你会编写完全不同的代码来修复 DEV 或 REL 分支中的相同问题）。
当全新版本的开发完成时，您必须测试从 REL 迁移的新功能和补丁。如果一切正常，您将可以部署全新的大版本，并将当前的 DEV 归档到 REL，而旧的 REL 现在将被封存。
于 2009-05-13T10:54:43.713 回答