有没有人有过提前发布/经常发布商业软件的经验/例子？有用吗？
我在考虑 VMware，他们在每个主要版本之间都有很多修订版本。而且安装体验很糟糕，有时它们会破坏现有的虚拟机，有时客户操作系统中的 VMware Tools 会出现故障/无法安装。太可怕了。
我也在考虑 ClickOnce 部署，因为当您更新软件时使用 ClickOnce，所有客户端都会自动收到发布通知，并且只需单击一下，它们就会更新到新版本。如果您的软件有错误，那么它们也会自动“升级”以获取这些错误。
您是否有将提前发布/经常发布原则应用于商业软件的经验\示例\建议？
我希望将它应用到一个。
【问题讨论】：
标签： release release-management
肯尼是对的：这取决于。
我们致力于企业软件，客户可以在其中运行 3 个月以上的内部项目以升级到新版本。在那种环境下，频繁发布不起作用。客户将使用旧版本多年，我们必须继续支持他们，因此活跃的版本越多，支持工作就越多。
在另一个极端，我正在运行 Google Chrome 并阅读了有关更新测试版的信息。我去看看如何获取它，发现Chrome已经更新了自己。如果有任何通知我错过了，那对我来说很好。
主要问题是新版本的破坏性有多大。例如，如果 MS 每 3 个月发布新版本的 Visual Studio，其中包含新的 .NET 版本、C 运行时等，那么我们将花费大部分时间来处理升级，这并不好。但是，如果他们想发布新版本的 Windows 媒体播放器，其中包含一些适合我的新小部件 - 只需让下载/安装过程尽可能无缝。
【讨论】：
我认为这始终取决于您的市场或客户群。更改/升级软件总是很痛苦，在某些环境和公司中甚至更加痛苦。快速发布周期可能具有破坏性。这些中断通常也会扩展到您的内部运营，具体取决于营销/管理部门对功能蔓延的管理程度。
因此，经典的“视情况而定”答案再次响起。
如果您确实在为产品增加价值，然后客户尤其是新客户会想要它。最好的情况是消除升级更改的痛苦，因为它的工作原理相同，但明显更好。太好了。
【讨论】：
注意窗帘后面的人。：
早期发布 - 经常发布实践希望您做的事情是尽早快速地失败，而不是在项目结束时为时已晚。它使您有更多机会向最终客户展示您正在构建的内容，获得有价值的反馈并以更低的成本进行调整。 “客户”角色的人必须能够轻松获得最新版本；尽可能定期地尝试并提供建设性的反馈。
如果您正在构建一些关键的东西，例如监视或控制发电厂的东西，您可能需要小心这种做法。您不希望人们拿着手电筒作为您新版本的反馈。在这种情况下，定期部署到测试平台，观察 X 天（根据您的信心水平）然后上线是有意义的！您可以让您的客户访问此测试平台，以发挥并建立他的信心表。
如果它是一个非关键应用程序，并且您拥有良好的发布历史记录，请执行 ClickOnce 之类的操作。但还要确保它同样容易为客户回滚。
【讨论】：
如果您打算这样做，请确保当人们购买您的产品时，他们将在一年或其他一段时间内免费升级到新版本，这样他们就不会觉得自己被骗了当他们购买副本后 2 个月发布新版本时。此外，请确保您支持旧版本，以便那些不想升级，只想修复错误的人可以这样做，而不会冒着用新版本的软件破坏他们当前安装的风险。我个人认为这会带来更多的工作量，但您最终会得到更好的产品，并且如果他们愿意，您将允许使用您的软件的人们更快地利用新功能。
【讨论】：
我们运行一个 SaaS 应用程序，因此原则上它可以随时更新。
另一方面，在实践中，它每年只发布几个主要版本（通常每隔几周发布一次较小的补丁版本）。
原因是发布会给操作人员造成干扰；有时需要删除部分应用程序。对于非面向客户的更改，实际进行发布而不是进行工程设计需要大量工作。
因此，虽然 StackOverflow 似乎每隔几天就会更新一次，但我们不会这样做。一天之内可能会修复几个错误，但它们会在随后的版本中得到修复，该版本以“大爆炸”的形式发布。什么的。
【讨论】：
这取决于您的资源。如果您是微软，您可以提前发布一个与 Sista 押韵的漏洞百出的 POS，并依靠您的营销能力让人们忘记他们对产品的早期体验。
如果您希望获得良好的口碑，发布早期版本并不是一个好主意（除非您计划在最终发布之前更改名称或其他内容）。
【讨论】：