使用Drools Guvnor进行规则开发和部署管理

Question

简介

Drools Guvnor拥有自己的版本控制系统，在生产中使用允许应用程序的用户修改规则和决策表，以适应他们业务的变化。然而，相同的资产继续存在于开发版本控制系统中，其中开发了应用程序的新功能。

这篇文章是为了在使用Drools规则和Guvnor时查看有关规则开发和部署的见解/想法/经验。

以下是我一直困惑的一些关键概念。

部署到Guvnor

首先，将drl文件和决策表部署到生产环境的最佳方法是什么？只需将它们放在一个zip包上，然后解压缩到Web-Dav文件夹？我在Drools周围导航，我没有找到一种方法一次导入多个文件。但是，事实模型可以添加为jar存档。 Guvnor似乎有某种REST API，但使用它需要自定义部署脚本。

变更管理

其次，一旦应用程序投入生产，用户可能希望更改决策表中的值，以便为高级客户等设置更高的折扣百分比。这一切都很好，花花公子，直到时间到了开始开发应用程序的2.0版本。

现在我们所拥有的是

• 在版本控制系统
中运行文件和决策表
• 生产环境中的文件和决策表，用户修改，由Guvnor版本化

现在我们正在从Guvnor获取规则和决策表。 Web-Dav文件夹最适合这个，还有其他选择吗？

今天的合并工具甚至可以处理Excel文件差异，但听起来像是在大型项目中合并到我身上。

保持事实模型向后兼容

另一个话题是事实模型的完整性。对于假定的2.0版本，开发人员总是希望进行重构并将整个事实模型颠倒过来。尽管如此，它仍然必须保持向后兼容以前的版本，因为可能存在依赖于此的用户修改规则。关于这个的任何提示？只是保持事实模型简单干净？提前计划/建议用户想要改变什么？

摘要

我确信我不是第一个，也不是最后一个，考虑使用Drools和Guvnor进行部署和变更管理的选项。所以，我想听到的是关于处理这些情况的一些最好的（也是最糟糕的，以避免它们）做法的评论，讨论，提示等。

感谢。

Answer 1

做事的最佳方式在很大程度上取决于您的具体应用和您所处的环境。但以下是我自己的经验指针。请注意，我现在只添加几点。当事情发生时，我可能会回到这个答案。

在首次上线后，保持版本增量和小

首次发布时，您有机会尝试一下。利用这个机会，尽可能多地进行重构，因为......

您的应用程序已经上线，您的业务用户正在维护决策表中的规则。你已经在业内人士称之为“业务敏捷性”方面取得了巨大成就。不幸的是，这往往会牺牲应用程序开发的灵活性。您的所有指导编辑器规则和决策表规则都与您的事实模型相关联，因此任何更改该事实模型的现有属性都将破坏您的决策表。与大多数IDE不同，您不能只是右键单击事实的getX（）方法，重命名它，并期望更新依赖于该属性的所有代码。

决策表和指导规则难以重构。如果已经重命名了一个事实，那么在许多（全部？）版本的Guvnor中，该规则/表将不再打开。您需要通过WebDav获取基础XML文件并进行一些文本搜索和替换。这可能非常困难，考虑到要做到这一点，您需要将文件从生产下载到测试环境，进行更改，测试它们，将它们部署到测试环境中。当您对更改感到满意时，您需要将它们推回到“生产”Guvnor。不幸的是，当您这样做时，用户已经更新了许多决策表，您需要重新开始，或者重新应用过去几天的更改。在理想的世界中，您的业务用户将同意在一段时间内不进行规则更改。但实现这一目标的唯一方法是保持较小的变化，以便您可以在几个小时或一天内制作它们，具体取决于它们的慷慨程度。

要缓解这种情况：

1. 将Guvnor中使用的事实与应用程序域类分开。然后，您的应用程序开发人员可以将内部应用程序模型重构为内容，但此类更改不会影响业务模型。保持两者之间的映射，并确保有测试覆盖这些映射。
2. 避免更改，例如重命名事实或其属性。确保您创建的事实及其属性具有适合该域的名称，并与业务部门达成一致。另一方面，添加新属性相对无痛。非常值得提示用户关注他们未来的计划。
3. 尽可能简化事实。除非你真的需要，否则不要比名称 - 值对更复杂。首先，您的业务用户会发现维护规则要容易得多。 Guvnor内部管理的任何内容的优先级应始终是让业务用户轻松维护。
4. 保持外部依赖性不受事实影响。开发人员可能认为将事实注释为JPA @Entity是一个好主意，以便于持久化。不幸的是，这会增加需要添加到Guvnor类路径的依赖项，需要重新启动。

提示＆amp;技巧

我进行跨环境更改的个人技术是将Eclipse连接到两个Guvnor WebDav目录，并将规则签入本地目录，其中每个本地目录都映射到一个环境。然后我使用Eclipse diff工具。

在构建Guvnor管理的知识库时，我创建了一个单独的Maven项目，该项目仅包含事实，并且不依赖于任何其他内容。这样可以更容易地保持它们的清洁。此外，当我确实需要添加一个依赖项（即我尽可能使用JodaTime）时，构建可以有一个步骤来生成包含所有依赖项的着色JAR。这样，您只需要将一个JAR部署到Guvnor，这可以保证包含正确版本的依赖项。

我相信我会想到更多。我会记得回到这个......