到目前为止，我们的“最佳实践系列”专注于初级规则编写。我现在想退一步，从一个更高层次的视角来看。规则创建完成后，应该怎么做？在本系列中，我们将讨论生命周期管理和测试之类的主题。今天，我们来谈谈发布管理。

什么是发布管理？

你肯定对版本控制很熟悉，这是一种记录存储库中每次修改的功能。版本控制通常是开箱即用的，不依赖用户进行设置或明确创建版本。这样，你可以每天看到是谁做了修改，内容，时间和原因（如果他们提供了注释）。

发布管理从一个更高层次的视角来看待变更管理。创建发布时，将冻结决策中的每个规则的状态。从概念上讲，发布是对冻结在某种状态下的决策的封装。之后对项目的更改在该发布中不可见。

尽管每种决策管理产品都是不同的，但我们始终认为，这些产品不应创建规则项目的副本。发布应该只指向决策内容的清单。它不应该复制规则。

为什么要创建发布？

第一个也是最重要的原因是敏捷性。把更改部署到决策中时，我们希望规则会随着时间的推移而不断改进。不幸的是，预料之外的问题会隐藏在决策逻辑中，并逃过QA工作。例如，过于激进地更改阈值可能会严重影响拒绝率。尽管这在执行方面是正确的，但它可能不符合业务目标。

发生这种情况时，发布管理可以通过“一键点击”来定位之前的发布。在原到先前的决策状态后，团队可以同步改善决策逻辑。执行引擎不需要知道哪些规则已更改并需要还原。执行引擎只需加载要替换的配置。

相关但略有不同的是同时加载多个配置的能力。对于渐进式的改进，发布可以较为轻松地做到用“旧”规则持续处理大部分的业务，以及用“新”规则处理剩下的5％到10％的业务。当对新逻辑感到满意，就可以将所有业务按决策的最新发布处理。

最后，透明拥有巨大的价值。通过发布，你可以在任何时间点追溯到处理给定事务时的规则状态。我们已经看到这种功能在司法诉讼或内部调查情况下的必要性。无论是什么原因，某个发布过的版本应该是始终可访问的。作为一个冻结的副本，已经发布的版本中的规则不能从技术层面上被修改。你可以认为你所看到的历史规则就是在那个时间点所执行的规则。然后，你就可以利用各种调查工具来了解当时是如何做出决策的。

总之，如果你没有使用发布，则应该尽早利用。另外，借助自动生成的“差异”文档，可以更轻松地追溯发布之间的变更。确实没有理由不使用发布！