java - 在生产环境中使用带有Elasticsearch alpha 3版本的Hibernate Search有什么危险？

Question

我正在开发一个电子商务应用程序，正在将基于Spring MVC 4注释的配置与hibernate和MySQL一起使用。我需要集成搜索引擎，因此我决定继续使用hibernate flex 搜索。 我需要知道在生产环境中使用Hibernate search alpha 3是否会对我的电子商务Web应用程序构成任何威胁？如果Alpha版本是一个威胁，那么对我来说有什么替代解决方案？

Answer 1

代表Hibernate Search小组回答(我是项目负责人)。

当我们发布任何东西时，我们认为这是好的代码，并且我们认为实现的功能是可靠的。您可能会认为它类似于为自己的项目编写任何代码并考虑“完成后，这将很好地完成工作”。

但是，尽管我们以编写出色代码为目标而感到自豪，但我们是人类，有时甚至是错误的。

我们正在各种环境和OS组合中进行测试，任何提交请求都将由另一个提交者进行同行审阅，并且可以接受任何人的审查(全都是public on github)，因此我想说质量通常很高。

使用任何非最终版本会有什么风险？

环境

尽管我们测试了OS，JDK，数据库，硬件类型(小型嵌入式到非常高端的服务器)的许多组合，但是我们可以测试的组合是有限的:Red Hat赞助了我们，但预算不是无限的。

当您全部下载Alpha / Beta并在您的环境中对其进行测试时，您可能会遇到一些我们不知道的极端情况。
帮个忙，让您的团队定期测试对您而言重要的预览版环境:如果失败并可以报告，我们将确保该版本适用于最终版本。

这样做有几个人的帮助，所以决赛将有更好的报道。但是，请考虑在您自己的环境中进行测试，以便满足您的特定要求。

因此，当您将Alpha投入生产时，它可能仍然存在与我们尚不了解的某些环境相关的问题。不过，您可以查看我们的问题跟踪器，以查看其他志愿者报告的任何问题是否会打扰您:如果未报告任何问题，则更改为下一个版本不会比Alpha更加“可靠”，而是再次相同。

测试范围

我们开发了各种单元测试和集成测试，以及性能测试，以涵盖新功能并防止出现退化。

其他人可能会尝试以我们意想不到的方式使用这些新功能，或者只是在我们的测试未涵盖的字段和类型组合上使用这些新功能。

当您下载我们的预览，并用它来解决您的要求时，这可能会发现我们未涵盖的问题。确保最终版本适合您的要求的最佳方法是尽早试用，然后让我们知道哪些还不好。

如果您向我们发送了一个补丁程序，其中添加了用于您的用例的单元测试，您将获得非常高的投资返回:我们会将该测试包含在我们的代码库中，以便持续集成将确保您的需求得到满足以及将来的版本。

当然，如果您尝试了并且工作正常(正如我们期望的那样)，那么您最好将其投入生产，只要您了解以下有关Alpha与Final的区别的要点。

那么Alpha版和Beta版之间有什么区别？

通常，它与功能覆盖率有关。

对于Beta版本，我们通常要求它“功能完整”:实现所有我们认为您需要从新功能中受益的功能。

这种情况下的一个示例可能是5.6的Alpha版本(第一个支持Elasticsearch的版本)没有重建索引的功能。我认为，出于各种实际原因，具有此选项是必不可少的，但是如果您的特定用例不需要它(您可能有自己的策略？)，那么缺少这样的功能可能不会打扰您。

Beta版本将包含所有有关测试Alpha版本的信息的修复程序。因此，它可以在您的环境中“正常工作”的机会更高。

Beta版和候选版本或最终版之间有什么区别？

在publishing the Beta1 release之后，我们可能仍有待处理的工作，但是我们希望新功能的API不再更改。除非有人有重大和合理的顾虑。

因此，我们希望甚至会有更多的人乐于测试Beta，并且当我们收到足够的反馈，例如“效果很好!”时， (我们很高兴听到这个消息，请告诉我们!)，然后我们打了电话，说已经有足够的人对其进行了测试，然后将其称为“最终发行版”-可能还有候选版本，使人们有最后的尝试机会。

在这一点上，现在告诉我们某些API令人困惑，建议您使用不同的名称命名方法，等等，可能为时已晚。因此，请确保尽早针对您的项目尝试该方法。

我希望这有助于为您的特定用例做出明智的选择。

在准备生产方面:我认为Alpha就像编写自己的集成一样准备就绪；只需确保像测试您自己团队的代码一样对其进行测试，并详细研究发行说明，以同样了解已知的局限性即可。

这在很大程度上取决于您如何处理它的潜在问题:我不建议在关键任务系统上使用它，但是有些人最终会获得更好的集成，因为他们可以在与生产非常相似的环境中测试早期版本，或者可以处理已经生产的风险。