商业软件经常发布/发布?

时间:2008-11-08 13:45:35

标签: release release-management

是否有人提供有关商业软件的早期发布/经常发布的经验/示例?它有效吗?

我在想VMware,他们在每个主要版本之间都有很多版本。安装体验非常糟糕,有时它们会破坏现有虚拟机,有时客户操作系统中的VMware Tools会出现故障/无法安装。这太可怕了。

我也考虑过ClickOnce部署,因为在更新软件时使用ClickOnce,所有客户端都会自动获得发布的通知,只需单击一下,它们就会更新到新版本。如果您的软件存在错误,那么它们将自动“升级”以获取这些错误。

您是否有经验\示例\建议将早期发布/经常发布原则应用于商业软件?

我希望将它应用到一个。

6 个答案:

答案 0 :(得分:6)

肯尼是对的:这取决于。

我们致力于企业软件,客户可以运行内部3个月以上的项目升级到新版本。在该环境中,频繁发布工作。客户将保留旧版本多年,我们必须继续支持它们,因此活动的版本越多,支持工作就越多。

另一方面,我正在运行谷歌浏览器并阅读有关测试版刷新的信息。我去了解如何获得它并发现Chrome已经更新了。如果有任何通知我错过了,那对我没问题。

主要问题是新版本的破坏性。例如,如果MS使用新的.NET版本,C运行时等每3个月发布一次Visual Studio的新版本,那么我们将花费大部分时间来处理升级,这不会很好。但是,如果他们想要发布一些新版本的Windows媒体播放器,并且我可以使用一些新的小部件 - 只需使下载/安装过程尽可能无缝。

答案 1 :(得分:3)

我认为这总是取决于您的市场或客户群。在某些环境和公司中,更改/升级软件总是很痛苦,甚至更痛苦。快速释放周期可能具有破坏性。这些中断通常也会扩展到您的内部操作,具体取决于营销/管理对功能蠕变的管理程度。

因此,经典的“依赖”答案会再次响起。
<如果您真的为产品增加价值,那么客户尤其是新客户会想要它。最好的情况是,删除升级更改的痛苦,因为它的工作方式相同,但在明显的方面更好。大。

答案 2 :(得分:2)

注意幕后的男人。
早期发布 - 发布通常需要你做的事情就是早期和快速失败,而不是在项目结束时失败。它为您提供了更多机会向最终客户展示您正在构建的内容,获得有价值的反馈并以较低的成本进行调整。 “客户”角色的人必须能够轻松获得最新版本;与它一起玩,并尽可能定期回应建设性反馈。

如果您正在构建重要的内容,例如:监视或控制发电厂的东西,你可能要小心这种做法。你不希望有火把的人作为你的新版本的反馈。在这种情况下,定期部署到试验台,观察X天(根据您的信心水平)然后去现场是有意义的!您可以让您的客户使用此试验台进行游戏并建立他的信心表 如果它是一个非关键应用程序并且您已经获得了良好版本的良好历史记录,请执行类似ClickOnce的操作..但也要确保它同样易于为客户回滚。

答案 3 :(得分:1)

如果您要这样做,请确保当人们购买您的产品时,他们可以免费升级新版本一年或其他一段时间,这样他们就不会觉得他们被扯掉了当他们买了一个副本2个月后出现新版本。此外,请确保您支持旧版本,以便那些不想升级,只需要修复错误的人可以这样做,而不会冒险使用新版本的软件破坏他们当前的安装。我个人认为这将是更多的工作,但你最终会得到一个更好的产品,并且如果他们选择的话,你将允许使用你的软件的人更快地利用更新的功能。

答案 4 :(得分:1)

我们运行SaaS应用程序,因此原则上它可以随时更新。

另一方面,在实践中,它每年只获得少量主要版本(通常每隔几周推出较小的补丁版本)。

原因是发布会对运营人员造成干扰;有时应用程序的一部分需要删除。对于非面向客户的更改,实际上执行发布的工作与进行工程相比有很多工作。

因此,虽然StackOverflow似乎每隔几天就会更新一次,但我们不会做那样的事情。可能会在一天内修复几个错误,但它们会在随后的版本中修复,后续版本将作为“大爆炸”发布。或者其他什么。

答案 5 :(得分:0)

这取决于您的资源。如果您是MicroSoft,您可以提前发布与Sista押韵的错误POS,并依靠您的营销能力让人们忘记他们早期的产品体验。

如果您希望获得良好的口碑,发布早期版本并不是一个好主意(除非您计划在最终版本发布之前更改名称或内容)。