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

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

这篇文章是为了在使用Drools规则和Guvnor时，寻找关于规则开发和部署的见解/想法/经验

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

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

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

现在我们在这一点上得到的是

• 版本控制系统中的drl文件和决策表
• 生产环境中带有用户修改的drl文件和决策表，版本由Guvnor控制

现在我们要从Guvnor获取规则和决策表。再说一遍，Web Dav文件夹是最好的吗？还有什么其他选项

今天的合并工具甚至可以处理Excel文件差异，但对我来说，在大型项目中，这听起来像是一个合并地狱

保持事实模型向后兼容 另一个主题是事实模型完整性。对于假定的2.0版本，开发人员总是希望进行重构并将整个事实模型颠倒过来。尽管如此，它必须与以前的版本保持向后兼容，因为可能有用户修改的规则依赖于此。有什么建议吗？保持事实模型简单明了？提前计划/建议用户希望更改的内容

总结 我确信我不是第一个，也不是最后一个，考虑用DooLS和Guvor部署和改变管理的选项。因此，我想听到的是关于处理这些情况的一些最佳（也是最坏的）做法的评论、讨论、提示等

---

谢谢。

做事情的最佳方式在很大程度上取决于您的特定应用程序和工作环境。然而，以下是我自己的经验。请注意，我现在只想补充几点。当事情发生时，我可能会回到这个答案上来

初始上线后，保持发布增量和小型化

对于第一个版本，您有机会尝试一下。利用这个机会，尽可能多地进行重构，因为

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

决策表和引导规则很难重构。如果一个事实被重命名，那么在Guvnor的许多（所有？）版本中，该规则/表将不再打开。您需要通过WebDav获取底层XML文件，并进行一些文本搜索和替换。这可能非常困难，考虑到要做到这一点，您需要将文件从生产环境下载到测试环境中，进行更改、测试并将其部署到测试环境中。当您对所做的更改感到满意时，您需要将其推回到“生产”Guvnor。不幸的是，当您这样做时，用户已经更新了许多决策表，您需要重新开始，或者重新应用过去几天的更改。在理想情况下，您的业务用户将同意在一段时间内不更改规则。但唯一可行的办法是保持小幅度的改变，这样你就可以在几个小时或一天内完成，这取决于他们的慷慨程度

为了缓解这种情况：

将Guvnor中使用的事实与应用程序域类分开。然后，您的应用程序开发人员可以将内部应用程序模型重构为自己的核心内容，但这些更改不会影响业务模型。维护两者之间的映射，并确保有覆盖这些映射的测试

避免更改，例如重命名事实或其属性。确保您创建的事实及其属性的名称适合该域，并与业务一致。另一方面，增加一个新的属性相对来说比较容易。值得提醒用户关注他们的未来计划

让事实尽可能简单。除非您真的需要，否则不要比名称-值对更复杂。首先，您的业务用户会发现维护规则要容易得多。对于Guvnor中管理的任何内容，您的首要任务应该始终是使业务用户易于维护

将外部依赖性排除在事实之外。开发人员可能认为将一个事实注释为JPA@实体是一个好主意，以便于持久化。不幸的是，这增加了依赖性