一个大版本还是几个小版本？

Question

当您正在对现有业务线应用程序进行增强时，您认为更好的做法是将更改批量处理到频率较低的较大版本中，还是在较小版本中不断发布新功能？假设有硬件升级或数据库升级，您是也随版本进行这些更改，还是将它们分开？

将所有内容一起发布的好处是，对业务的中断更少，涉及的非工作时间也更少，但您以后遇到的任何问题都可能是由于数据库升级、硬件或任何数量的软件更改造成的。

发布很少，通常可以更容易地跟踪发布导致的任何问题，但会导致更多的中断和更多的时间花费在回归测试上。

哪种更好些呢？

Answer 1

考虑每个版本对客户的影响。频繁的小版本发布会因为更快地解决关键问题而让他们更高兴吗？这会提高你的销量和声誉吗？如果它会仔细估计这些好处是否超过了所做的额外工作，否则只需遵循对您更方便的路径。

Answer 2

这真的取决于你所处的环境。一些场景：

许多客户:您希望所有客户都有相同的版本，尽可能。年度、半年度或季度大型发布要容易得多，因为测试和部署协调非常昂贵。在这种情况下，我也会包括对db的更改。

“大型基础设施”：如果在大型公司环境中工作，有专门的操作系统和数据库人员，那么发布的总体成本也很高，因此发布频率较低的较大版本更好。

简而言之，计算释放人力、业务中断、协调、测试的成本，并将其与每个新功能或错误修复的好处联系起来。

我通常一年会发布1-2个大的版本，并在其间修复bug，以阻止节目的播放。

Answer 3

我认为最好的答案是:两者的混合体。

例如，如果你添加了一些令人眼花缭乱的东西，或者让textbox的名字更像"ajaxy"，或者可能加入了一个新类型的报表--把它设为“小”版本。尽早发布，并尽可能经常发布。

另一方面，如果你改变了一个面向用户的流程，迫使用户接受“再培训”，或者如果你需要大规模的基础设施改变--去做一个大的发布，并且尽可能少这样做。

正如您所说，如果很少或根本没有中断，那么尽可能多地这样做，您的用户会对此感到更高兴-而且您实际上将在回归测试上花费更少的时间，因为您只需要测试与您所做的更改相关的所有内容。