在生產中使用帶有Elasticsearch alpha 3版本的Hibernate Search有什么危險？

Question

我正在開發電子商務應用程序。我將基於Spring MVC 4注釋的配置與hibernate和MySQL一起使用。我需要集成搜索引擎，因此我決定繼續使用hibernate彈性搜索。 我需要知道在生產環境中使用Hibernate search alpha 3是否會對我的電子商務Web應用程序構成任何威脅？ 如果Alpha版受到威脅，那么對我來說有什么替代解決方案？

Answer 1

代表Hibernate Search小組回答（我是項目負責人）。

當我們發布任何東西時， 我們認為這是好的代碼，並且我們認為實現的功能是可靠的。 您可能會認為它類似於為自己的項目編寫任何代碼並考慮“完成后，這將很好地完成工作”。

但是，盡管我們為編寫出色的代碼而感到自豪，但我們是人類，有時甚至是錯的。

我們正在各種環境和OS組合中進行測試，任何請求請求都將由另一個提交者進行同行審閱，並且可以接受任何人的審查（ 在github上都是公開的 ），因此我可以說質量通常很高。

使用任何非最終版本會有什么風險？

環境

盡管我們測試了OS，JDK，數據庫，硬件類型（小型嵌入式到非常高端的服務器）的許多組合，但是我們可以測試的組合是有限的：Red Hat贊助了我們，但預算不是無限的。

當您全部下載Alpha / Beta並在您的環境中對其進行測試時，您可能會遇到一些我們不知道的極端情況。 幫自己一個忙，讓您的團隊定期測試對您而言重要的環境的預覽版：如果失敗並可以報告，我們將確保該版本適用於最終版本。

這樣做有幾個人的幫助，所以決賽將有更好的報道。 但是，請考慮在您自己的環境中進行測試，以便滿足您的特定要求。

因此，當您將Alpha投入生產時，它可能仍然存在與我們尚不了解的某些環境相關的問題。 但是，您可以查看我們的問題跟蹤器，以查看其他志願者報告的任何問題是否會打擾您：如果未報告任何問題，則更改為下一個版本不會比Alpha“更可靠”，而將再次相同。

測試覆蓋率

我們開發了各種單元測試和集成測試，以及性能測試，以涵蓋新功能並防止出現退化。

其他人可能會嘗試以我們未曾預料到的方式來使用這些新功能，或者只是在我們的測試未涵蓋的字段和類型組合上使用這些新功能。

當您下載我們的預覽並用於解決您的要求時，可能會發現我們未涵蓋的問題。 確保最終版本適合您的要求的最佳方法是盡早試用，然后讓我們知道哪些還不好。

如果您向我們發送了一個補丁程序，其中添加了用於您的用例的單元測試，那么您可以獲得很高的投資回報：我們會將該測試包含在我們的代碼庫中，以便持續集成將確保您的需求得到滿足以及將來的版本。

當然，如果您嘗試了並且工作正常（正如我們期望的那樣），那么您最好將其投入生產，只要您了解以下有關Alpha與Final的區別的要點。

那么Alpha版和Beta版之間有什么區別？

通常，它與功能覆蓋率有關。

對於Beta版本，我們通常要求它“功能完整”：實施所有我們認為您需要從新功能中受益的功能。

這種情況下的一個例子可能是5.6的Alpha版本（第一個支持Elasticsearch的版本）沒有重建索引的功能。 我認為，出於各種實際原因，具有此選項必不可少，但是如果您的特定用例不需要它（您可能有自己的策略？），那么缺少這樣的功能可能不會使您感到困擾。

Beta版本將包含所有有關測試Alpha版本的問題的修復程序。 因此，它可以在您的環境中“正常工作”的機會更高。

Beta版和候選版本或最終版之間有什么區別？

發布Beta1版本后，我們可能仍有待完成的工作，但是我們希望新功能的API不再更改。 除非有人有重大和合理的顧慮。

因此，我們希望甚至會有更多的人樂於測試Beta，並且當我們收到足夠的反饋，例如“效果很好！”時， （我們很高興聽到這個消息，請告訴我們！），然后我們打了電話，說已經有足夠的人對其進行了測試，然后將其稱為“最終發行版”-可能還有候選版本，使人們有最后的嘗試機會。

在這一點上，現在告訴我們某些API令人困惑，建議使用不同的名稱命名方法，等等，可能為時已晚。因此，請確保盡早針對您的項目嘗試該方法。

我希望這有助於為您的特定用例做出明智的選擇。

在准備生產方面 ：我認為Alpha就像編寫自己的集成一樣准備就緒； 只需確保像測試自己團隊的代碼一樣對其進行測試，並詳細研究發行說明，以同樣了解已知的局限性即可。

在很大程度上取決於您如何處理它的潛在問題：我不建議在關鍵任務系統上使用它，但最終人們會獲得更好的集成，因為他們可以在與生產非常相似的環境中測試早期版本，或者可以處理已經生產的風險。