什么是规则的生命周期管理？

业务规则将公司从传统的软件开发生命周期（SDLC）中解放出来，但这并不意味着它们无需任何治理即可创建和部署。以我的经验，实际上可以通过更好的控制来跟踪业务规则。从长远来看，这些决策逻辑更改的可追溯性是一个巨大的好处。让我说明在现实生活中实际使用和利用决策逻辑生命周期管理的几种方法。

从低级版本开始

这是可追溯性最广泛使用的级别。绝对需要对业务规则进行版本控制的原因是显而易见的：如果有人错误地删除了所有业务规则，您会感觉如何？这就是为什么我们在源代码管理系统中使用版本控制，甚至在文档管理系统中使用版本控制的原因。我们想确保这些资产受到保护，如果发生更改，我们想知道是谁进行了这些更改，如果发生了重大更改，我们希望能够恢复到原始版本。

在接下来的文章中，我将对版本控制有更多的话要说。但是，我想关注生命周期管理的更多有趣方面：如何安全地从创作环境到生产环境获取决策逻辑。

将业务规则发布到另一个环境

我见过很少有在生产环境中发生业务规则更改的情况，但实际上，您肯定希望至少有几个不同的环境将开发与部署分开。在创建或修改的业务规则迁移到生产系统之前，应对其进行测试。IT部门不会让您实时进行这些更改。

企业可以通过两种方式发布其业务规则：

• 增量式

• 打包方式

采用增量方法，您可以隔离或添加，更改，测试它们并独立于项目其余部分进行部署的几个规则。例如，您可以使用标签来标识这些业务规则，并使用过滤器仅将带有该标志的项目推送到目标环境中的项目当前状态。使用这种方法的好处是您可以进行许多更改-假设需要修改或添加20条规则-并且仅选择准备发布（经过测试和批准）的6或7条规则。不需要规则编写者按顺序处理这些更改。

以打包的方式，整个项目作为一个整体进行测试，并作为新的“部署程序包”进行迁移。我在这里没有具体说明部署程序包的含义，因为它可能在体系结构之间略有不同。这样的想法是，您将在生产系统中最终获得一个包含旧规则和新规则的新项目。好处是，它允许您（或IT部门）针对有效部署的内容运行所有质量测试。

无论采用哪种部署方法，发布操作都可以根据需要与自动测试，模拟和手动批准联系在一起。这样，您始终可以查看谁批准了更改以及相关的报告。

规则版本的回滚

在对变更进行提前测试和审查的同时，您有时可能希望回溯生产中的变更。为什么？假设您仅根据期望值测试了规则，而没有机会使用业务指标运行模拟。业务绩效可能与您的业务目标不符，正如我在现实生活中的项目中看到的那样，发送了太多的应用程序以进行手动检查。也可能是由于外部更改（例如新数据格式）最终与新业务规则不兼容。有许多原因导致您想要恢复到业务规则的先前版本。

一种实现方法是返回到您的开发环境，并使用低级版本控制机制来恢复所讨论规则的最新版本，然后再次发布它们。尽管这项技术已经使用了多年，但是它需要大量的纪律以确保您找到并更新所有相关的业务规则，并且仅是这些规则。

另一种方法是利用发布机制。使用增量方法，则要困难一些。但是，如果您使用打包方法，则可以定位最后一个“好的”程序包，然后重新部署它。从历史上看，此方法已被更频繁地使用，因为它使您可以快速访问经过完全测试的业务规则包。

处理这种“时间旅行”的更好方法是使用发布的概念。对于每个项目，您可以创建项目视图并及时冻结，然后参考该视图以执行。这种机制的优点在于，它允许您同时在生产环境中部署不同的发行版。为什么要这么做？我看到两个主要的用例。首先，您可能希望将新规则仅应用于整体生产事务的一部分。通过使用发行版，您可以针对发行版8的大部分事务执行交易，并将选定的样本路由到发行版9。无论是作为安全措施还是冠军/挑战者实验，使用发行版管理都具有这种灵活性。第二种情况与级联环境有关。如果这些业务规则的内部或外部客户不同，您可能需要让他们有时间升级到新版本。在一段时间内，您可能需要为落后的客户端支持版本8的并发执行，对于领先的客户端则需要支持版本9。再次，发布管理使您可以同时运行同一项目的多个发布。我警告您不要尝试通过重复规则来做到这一点。这可能是该博客的另一个主题。

关于生命周期管理以及我刚刚描述的许多技术的好处是它们都是兼容的。您不必依赖单一的机制，可以根据您的特定需求对其进行分层，并结合各种优势。