您是否使用预发布软件开发商业产品?

时间:2009-04-03 12:39:36

标签: architecture

所以问题是..您是否使用过预发布产品或技术(社区技术预览,测试版或候选发布版等)来开发自己的产品?

例如,您可能使用Microsoft的ASP.Net MVC开发了一个网站(昨天刚刚进行了RTM)或构建了针对SQL Server 2008 RC 1..etc的软件

如果是这样的话。

1.您(或您是否)采取了哪些措施来最大程度地降低预释放产品正确释放时出现问题的风险?

2.在使用产品之前,您是否等待特定的时间范围(例如产品是候选发布者)?

3.使用预发布技术的主要优势(与风险相比)是什么?

10 个答案:

答案 0 :(得分:6)

几乎所有我曾经访问过的成功软件项目都已经发布(嗯,已发布 - 网站),并且正在使用相当数量的测试版。

我们主要评估这些(主要是开源项目)的测试覆盖率以及之前没有做过愚蠢事情的记录。

只要符合我们的要求,任何旧的测试版都会发挥作用;)但是通常我们会在重大改写之后不再使用即时快照。

这些天我们是测试驱动的,所以我们知道我们的的东西是否有效。如果库有bug,我们会使用旧版本或修复bug。我们还可以立即评估更新是否存在严重错误,因为它会破坏我们自己的测试。所以使用“未完成”软件真的不是什么大问题。访问最新功能始终是原因,有时我们会这样做以获得重要的修复。

答案 1 :(得分:4)

除非我真的需要一些东西,否则我倾向于等到更广泛的市场经过测试后再与他们一起解决问题。我不只是为了它而采用新的东西。在我使用它之前,我想要看到它的眼睛数量。

在为我设计/开发系统方面存在足够的挑战,而无需开辟基础设施。

显然,如果客户采用早期技术发布,那么我的手就会被迫。

答案 2 :(得分:1)

这取决于您对该软件的信任程度 - 基本上它会比您当前的软件更有效地解决用户的问题。因此,当asp.net 2.0首次预览时,我们立即接受它(因为我们认为它比asp.net 1.1有了很大的改进)

但对于asp.net mvc则不然。现在,如果我们决定采用下面的预览软件,那么我的答案就是3个问题:

关于你的第一点 - 你最近使用IDE获得的进步 - 就最终版本的代码破解而言,风险很小。这些公司在提前告知变化方面做得很好。更大的风险是 - 无论该技术是否会被大众采用,您的客户是否愿意为此付出额外的代价。

关于你的第二点 - 不,如果我们对一个新版本有强烈的感觉,那么在它发布的那一刻,我们就开始研究它以获得额外的优势。

关于你的第三点 -

优势 - 如果软件是一个成本低廉的解决问题解决方案 - 那么你作为早期采用者就已经获得了大奖。你可以为这些技能收取更多费用,因为显然会有更少的供应和更多的需求

风险 - 如果软件没有被大众所接受 - 你投入的时间和金钱就会流失; - )

答案 3 :(得分:0)

我没有。

在开始将产品用于商业目的之前,我通常会等到Service Pack 1。

我发现在我违反这条规则的奇怪场合,它最终会给开发人员造成很多不必要的压力和压力,以解决问题。

答案 4 :(得分:0)

有时我们需要修复错误或改进性能。如果FAE(现场应用工程师)说它稳定,我愿意尝试。

答案 5 :(得分:0)

对我来说,这完全取决于将产品推向市场所需的时间。例如,我在Silverlight工作。 SL3中可用的一些功能对于下一版本的软件是必需的。如果我们想在SL3成为RTW之后快速发布,那么我们需要针对测试版进行开发。我们不能等那么久。

答案 6 :(得分:0)

这取决于具体情况。在之前的工作中,我们使用了ADO.NET实体框架,但仍处于测试阶段。我们彻底测试了测试版,我们使用自动化单元测试和代码覆盖率分析来确保我们彻底。测试版通过了测试。

这是一个很好的举动。它为我们节省了三个月的最终版本等待时间,并且只花了几个小时来修复测试版和发布版之间的重大变化。

我不会使用的是预发布软件,我不确定是否会发布或得到很好的支持。这包括开源软件,除非我愿意自己支持。

答案 7 :(得分:0)

如果您的产品已发货或安装在客户端计算机上,请务必小心。

对于基于Web的系统(包括像Silverlight这样的组件),它是可能的。 我以前的公司部署了基于ASP.NET beta的系统(在它正式发布之前)。

在某些情况下(例如,您需要的突破性技术),这可能是一个很好的选择。但是,强烈的警告点:代码越多,您就必须更改。 Beta产品没有预期的寿命,支持或遗留考虑因素。因此,您应该期望必须替换基于测试版产品的任何代码构建。

对我来说,除非绝对必要,否则我几乎肯定会避免这种情况。问问自己:为什么使用测试版?如果这是一个非常好的答案,只需考虑风险。否则,跑你的车。 ;)

答案 8 :(得分:0)

有时你别无选择。例如,当该工具的新CTP版本将现有技术吹走时。

例如:

当Windows Workflow Foundation发布时,几乎没有其他选择。我们考虑了开发周期时间表(1年+),并意识到承担风险并开始使用CTp版本进行研究/开发将是有益的。结果证明它支付了该项目。

另一个例子是新的Sync Framework。它仅与SQL CE提供程序一起出现,尽管我们需要SQL EE / STD提供程序。我们与CE提供商进行了原型设计,并在新EE提供商发布时进行了升级。

我们唯一的选择是使用SQL Server合并复制或类似技术。啊!

答案 9 :(得分:-1)

根据经验,我从不在生产软件中使用这种不稳定的组件。

如果你需要质量,你应该建立在坚实的基础上。

我知道许多大型软件公司在成熟之前不会使用新的组件和技术 - 只是为了保持安全。

这一切都取决于你愿意接受的风险。

相关问题