我正在开发一个电子商务应用程序。我正在使用基于 Spring MVC 4 注释的配置与 hibernate 和 MySQL。我需要集成一个搜索引擎，所以我决定使用 hibernate 弹性搜索。我需要知道是否在生产环境中使用 Hibernate search alpha 3 会对我的电子商务 Web 应用程序构成任何威胁？如果 alpha 版本是一种威胁，那么对我来说有什么替代解决方案？
【问题讨论】：
标签： java spring hibernate elasticsearch hibernate-search
代表 Hibernate Search 团队回答问题（我是项目负责人）。
当我们发布任何东西时，在我们看来都是好的代码，并且我们认为我们实现的功能是可靠的。您可能会认为它类似于为自己的项目编写任何代码并考虑“完成，这将很好地完成工作”。
虽然我们为编写出色代码的目标感到自豪，但我们是人类，有时我们错了。
我们正在各种环境和操作系统组合中进行测试，任何拉取请求都由另一位提交者进行同行评审，并接受任何人的审查（都是public on github）所以我想说质量通常相当高.
环境
虽然我们在操作系统、JDK、数据库、硬件类型（小型嵌入式到非常高端的服务器）的多种组合中进行测试，但我们可以测试的组合是有限的：红帽赞助我们，但预算不是无限的。
当大家下载 Alpha/Beta 版并在您的环境中对其进行测试时，您可能会遇到一些我们不知道的极端情况。 帮自己一个忙，让您的团队定期测试我们在对您很重要的环境上构建的预览版：如果它失败并且您可以报告它，我们将确保它适用于最终版本。
有几个人通过这样做来提供帮助，所以决赛的报道会更好。但是请考虑在您自己的环境中对此进行测试，以便满足您的特定要求。
因此，当您将 Alpha 版推送到生产环境时，它可能仍然存在与我们尚不知道的某些环境相关的问题。不过，您可以查看我们的问题跟踪器，看看其他志愿者报告的任何问题是否会打扰您：如果没有报告任何问题，则更改是下一个版本不会比 Alpha 版“更可靠”，但还是一样。
测试覆盖率
我们开发各种单元测试和集成测试，以及性能测试以涵盖新功能并防止回归。
其他人可能会尝试以我们没有预料到的方式使用新功能，或者只是在您的测试中没有涵盖的字段和类型组合上。
当您下载我们的预览版并使用它来解决您的要求时，这可能会发现我们未涵盖的问题。确保最终版本适合您的要求的最佳方法是尽早尝试，并让我们知道哪些地方还不够好。
如果您向我们发送一个补丁，其中添加了一个单元测试来覆盖您的用例，您可以获得非常高的投资回报：我们将在我们的代码库中包含该测试，这样持续集成将确保满足您的要求将来的版本也将涵盖。
当然，如果您尝试过并且效果很好（正如我们所期望的那样），那么您不妨将其投入生产，只要您了解以下几点来区分 Alpha 和 Final。
通常是关于功能覆盖率。
对于 Beta 版本，我们通常要求它“功能完整”：要实现我们认为您需要从新功能中受益的所有内容。
在这种情况下，例如 5.6 的 Alpha 版本（第一个支持 Elasticsearch 的版本）没有重建索引的功能。我认为出于各种实际原因，拥有此选项是必不可少的，但如果您的特定用例不需要它（您可能有自己的策略？）那么缺少这样的功能可能不会打扰您。
Beta 版本将包含有关您在测试 Alpha 版本时告知我们的所有问题的修复。因此，它在您的环境中“正常工作”的可能性更高。
在publishing the Beta1 release 之后，我们可能还有一些未完成的工作要做，但我们希望新功能的 API 不会再发生变化。除非有人有重大且合理的担忧。
因此，我们希望更多的人乐于测试 Beta，并且当我们收到足够多的反馈时，例如“它运行得很好！” （我们很高兴听到这个消息，请让我们知道！）然后我们打电话说有足够多的人已经对其进行了测试，我们称其为最终版本 - 可能会有一个候选版本，让人们有最后一次尝试的机会。
此时告诉我们某些 API 令人困惑，您会建议使用不同名称的方法等可能为时已晚。因此请务必尽早为您的项目进行尝试。
我希望这有助于为您的特定用例做出明智的选择。
就为生产做好准备而言：我认为 Alpha 就像编写自己的集成一样准备好；只需确保像测试自己团队的代码一样对其进行测试，并详细研究发行说明，以同样了解已知的限制。
很大程度上取决于您如何处理它的潜在问题：我不建议在任务关键型系统上使用它，但有些人最终会获得更好的集成，因为他们可以在与生产非常相似的环境中测试早期版本，或者他们可以处理已经生产的风险。
【讨论】：