使用预发布开发工具进行开发

发布于 2024-09-25 18:12:46 字数 570 浏览 4 评论 0原文

我们正在开发一个网站。我们正在使用的开发工具之一已经发布了其下一版本的 alpha 版本,其中包括许多我们真正想要使用的功能(即它们可以使我们免于实现数千个功能)无论如何,行都可以做几乎完全相同的事情)。

我已经对其进行了一些初步评估,我喜欢我所看到的。问题是,我们应该开始真正使用它吗?即除了评估它之外,实际上将它用于我们的开发并依赖它?

作为 alpha 软件,它显然还没有准备好发布……但我们自己的代码也还没有准备好。它是开源的,我们拥有调试它所需的技能,因此理论上我们可以实际贡献错误修复。

但另一方面,我们不知道它的发布时间表是什么(他们还没有发布),虽然我觉得用它进行开发没问题,但我不太确定是否在生产中使用它,所以如果它在我们之前还没有准备好,那么它可能会推迟我们自己的发布。

你怎么认为?值得冒这个险吗?您有类似情况的经历(好的或坏的)吗?

[编辑] 我故意没有指定我们正在使用的语言或有问题的开发工具,以便保持问题的范围广泛,因为我觉得这是一个几乎可以应用于任何开发环境的问题。

[编辑2] 感谢 Marjan 非常有帮助的回复。我希望得到更多的回应,所以我对此给予了赏金。

We're developing a web site. One of the development tools we're using has an alpha release available of its next version which includes a number of features which we really want to use (ie they'd save us from having to implement thousands of lines to do pretty much exactly the same thing anyway).

I've done some initial evaluations on it and I like what I see. The question is, should we start actually using it for real? ie beyond just evaluating it, actually using it for our development and relying on it?

As alpha software, it obviously isn't ready for release yet... but then nor is our own code. It is open source, and we have the skills needed to debug it, so we could in theory actually contribute bug fixes back.

But on the other hand, we don't know what the release schedule for it is (they haven't published one yet), and while I feel okay developing with it, I wouldn't be so sure about using it in production so if it isn't ready before we are then it may delay our own launch.

What do you think? Is it worth taking the risk? Do you have any experiences (good or bad) of similar situations?

[EDIT]
I've deliberately not specified the language we're using or the dev-tool in question in order to keep the scope of the question broad, as I feel it's a question that can apply to pretty much any dev environment.

[EDIT2]
Thank you to Marjan for the very helpful reply. I was hoping for more responses though, so I'm putting a bounty on this.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

甜妞爱困 2024-10-02 18:12:46

我曾经有过为开源项目做出贡献的经验,就像你说的你希望做出贡献。他们忽略了补丁一年(当然他们有客户参加,尽管他们不销售软件而是支持)。一年后,他们拒绝了该补丁,因为没有其他解决方案来解决该问题,而且没有坚实的基础来做到这一点。我想这超出了他们当时的范围。

在您的情况下,我会尝试解决一两个优先级不那么高、已报告的错误,并查看它们的响应速度,然后做出决定。因为你在最后期限上的成功将受到他们的影响。如果您必须维护他们的工件的副本,那肯定会很痛苦。

简而言之:不仅评估产品,更评估生产者。

问候。

I've had experience contributing to an open source project once, like you said you hope to contribute. They ignored the patch for one year (they have customers to attend of course, although they don't sell the software but the support). After one year, they rejected the patch with no alternative solution to the problem, and without a sound foundation to do that. It was just out of their scope at that time, I guess.

In your situation I would try to solve one or two of their not-so-high priority, already reported bugs and see how responsive they are, and then decide. Because your success on deadlines will be compromised to theirs. If you have to maintain a copy of their artifacts, that's guaranteed pain.

In short: not only evaluate the product, evaluate the producers.

Regards.

诠释孤独 2024-10-02 18:12:46

我个人对此的看法是:不要。如果它们没有在你的时间范围内完成,你就会陷入困境,并且仍然需要自己输入数千行,并且可能会受到严格的时间限制。

话虽如此,我认为有一种方法可以让你尝试鱼与熊掌兼得。

如果您发现一种抽象方法,即将您自己的代码与库的代码隔离,例如使用适配器或外观模式,那么请继续使用 alpha 进行开发。但提前根据您的发布时间表确定您应该开始在适配器/外观后面开发自己的数千行版本的最新日期。如果那时 alpha 还没有变成 RC:微笑着忍受它并发展你自己的。

My personal take on this: don't. If they don't come through for you in your time scale, you're stuck and will still have to put in the thousands of lines yourself and probably under a heavy time restriction.

Having said that, there is one way I see you could try and have your cake and eat it too.

If you see a way to abstract it out, that is to insulate your own code from the library's, for example using adapter or facade patterns, then go ahead and use the alpha for development. But determine beforehand what the latest date is according to your release schedule that you should start developing your own thousands of lines version behind the adapter/facade. If the alpha hasn't turned into an RC by then: grin and bear it and develop your own.

吐个泡泡 2024-10-02 18:12:46

这取决于。

对于开源环境,它更多地取决于版本的质量,而不是它所具有的标签(alpha/beta/stable)。我使用过的 alpha 代码与其他生产商所谓的生产代码相比坚如磐石。

如果您拥有源代码,那么您可以修复任何错误,而对于闭源代码(通常是商业支持的),您永远无法发布使用测试版产品构建的生产代码,因为拥有代码的供应商不支持它,因此您可以不修它。

因此,在你的位置上,我将评估 alpha 版本的质量,然后决定是否可以投入生产。

当然,上述所有内容不适用于任何甚至远程安全关键的事物。

It depends.

For opensource environments it depends more on the quality of the release than the label (alpha/beta/stable) it has. I've worked with alpha code that is rock solid compared to alleged production code from another producer.

If you've got the source then you can fix the any bugs, whereas with closed source (usually commercially supported) you could never release production code built with a beta product because it's unsupported by the vendor who has the code, and so you can't fix it.

So in your position I'd be assessing the quality of the alpha version and then deciding if that could go into production.

Of course all of the above doesn't apply to anything even remotely safety critical.

厌倦 2024-10-02 18:12:46

这只是一个管理风险的问题。在开源中,alpha 版本可能意味着很多不同的事情。您需要准备好:

  • 处理 API 更改;
  • 提供错误修复和解决方法;
  • 自行测试稳定性、性能和可扩展性;
  • 更密切地跟踪变化,并决定是否采用;
  • 跟踪他们所取得的进展以及他们对补丁/问题的响应。

您确实使用持续集成,是吗?

It is just a question of managing risks. In open source, alpha release can mean a lot of different things. You need to be prepared to:

  • handle API changes;
  • provide bug fixes and workarounds;
  • test stability, performance and scalability yourself;
  • track changes much more closely, and decide whether to adopt then yet;
  • track the progress they are making and their responsiveness to patches/issues.

You do use continuous integration, do you?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文