问题描述
简介
Drools Guvnor有自己的版本控制系统，在生产使用中，该系统允许应用程序的用户修改规则和决策表，以适应其业务的变化。然而，相同的资产继续存在于开发版本控制系统中，在该系统中开发了应用程序的新功能。本文旨在寻找在使用Drools Rules和Guvnor时有关规则开发和部署的见解/想法/经验。
下面是我一直困惑的一些关键概念。
部署到Guvnor
首先，将DRL文件和决策表部署到生产环境的最佳方式是什么？只是简单地将它们放在一个压缩包中，然后解压缩到Web-Dav文件夹？我在Drools上浏览过的结果是，我还没有找到一次导入多个文件的方法。但是，可以将事实模型添加为JAR归档。Guvnor似乎有某种REST API，但使用它需要定制部署脚本。变更管理
其次，一旦应用程序投入生产，用户可能会希望更改决策表中的值，以便为高级客户等设置更高的折扣百分比。这一切都很好，直到开始开发应用程序2.0版的时候。
现在我们所拥有的是
- 版本控制系统中的DRL文件和决策表
- 用户修改的生产环境中的DRL文件和决策表由Guvnor进行版本控制
现在我们要从Guvnor那里拿回规则和决策表。再说一次，Web-Dav文件夹是最好的吗？还有其他选择吗？
今天的合并工具甚至可以处理Excel文件差异，但在我看来，在大型项目中合并简直就是地狱。
保持事实模型向后兼容
还有一个主题是事实模型的完整性。对于假定的2.0版，开发人员总是希望进行重构，并将整个事实模型颠倒过来。尽管如此，它必须保持与以前版本的向后兼容，因为可能会有用户修改的规则依赖于此。这方面有什么建议吗？只是保持事实模型的简单和干净？提前计划/建议用户可能想要更改的内容？摘要
我确信我不是第一个，当然也不是最后一个考虑使用Drools和Guvnor进行部署和更改管理的人。因此，我想听到的是关于处理这些情况的一些最好的(也是最坏的)做法的评论、讨论和提示等。
谢谢。
推荐答案
执行任务的最佳方式在很大程度上取决于您的特定应用程序和您所处的环境。然而，以下是我的亲身经历。请注意，我现在只补充几点。当我遇到问题时，我可能会回到这个问题上来。
首次上线后，Keep会以增量和小规模发布
对于您的第一个版本，您有机会进行尝试。利用这个机会，尽可能多地进行重构，因为...
您的应用程序已经启用，您的业务用户正在维护决策表中的规则。您已经在业内人士所说的"业务敏捷性"方面获得了巨大的收益。不幸的是，这往往是以牺牲应用程序开发敏捷性为代价的。您的所有指导式编辑器规则和决策表规则都绑定到您的事实模型，因此该事实模型的任何现有属性更改都将破坏您的决策表。与现在的大多数IDE不同，您不能只右键单击事实的getX()方法，重命名它，然后期望更新依赖于该属性的所有代码。
决策表和指导规则很难重构。如果一个事实已被重命名，那么在许多(全部？)Guvnor的版本，该规则/表将不再打开。您需要通过WebDAV获取底层的XML文件，并执行一些文本搜索和替换。这可能非常困难，因为要做到这一点，您需要将文件从生产环境下载到测试环境，进行更改，测试它们，然后将它们部署到测试环境。当你对你的改变感到满意时，你需要把它们推回到"生产"的Guvnor那里。不幸的是，当您这样做时，用户已经更新了许多决策表，您需要重新开始，或者重新应用过去几天的更改。在理想情况下，您的业务用户将同意在一段时间内不更改规则。但要做到这一点，唯一可行的方法就是把变化保持在很小的水平，这样你就可以在几个小时或一天内完成它们，这取决于它们的慷慨程度。
要缓解这种情况：
- 将Guvnor中使用的事实与您的应用程序域类分开。然后，您的应用程序开发人员可以重构内部应用程序模型以满足他们的需求，但这样的更改不会影响业务模型。维护两者之间的映射，并确保有覆盖这些映射的测试。
- 避免更改，如重命名事实或其属性。确保您创建的事实及其属性具有适合域的名称，并与业务一致。另一方面，增加一处新的房产相对来说是没有痛苦的。提醒用户关注他们未来的计划是非常值得的。
- 让事实尽可能简单。除非确实需要，否则不要进行比名称-值对更复杂的操作。首先，您的业务用户会发现维护规则要容易得多。在Guvnor内管理的任何东西，您的首要任务都应该是让企业用户易于维护。
- 将外部依赖排除在您的事实之外。为了便于持久化，开发人员可能会认为将事实注释为JPA@Entity是个好主意。遗憾的是，这会增加需要添加到Guvnor的类路径的依赖项，需要重新启动。
提示和技巧
我个人进行跨环境更改的技术是将Eclipse连接到两个Guvnor WebDAV目录，并将规则签出到本地目录中，每个本地目录都映射到一个环境。然后我使用了Eclipse diff工具。
在构建Guvnor管理的知识库时，我创建了一个单独的Maven项目，该项目只包含事实，不依赖于任何其他内容。以这种方式保持它们的清洁变得容易得多。此外，当我确实需要添加依赖项(即，我在可能的情况下使用JodaTime)时，构建可以有一个步骤来生成包含所有依赖项的阴影JAR。这样，您只需要将一个JAR部署到Guvnor，就可以保证它包含您的依赖项的正确版本。我相信会有更多我想到的事情。我会尽量记住回到这个...
这篇关于使用Drools Guvnor进行规则开发和部署管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！