So far, our Best Practices Series has focused on low-level rules writing. I would like to take a step back for a moment, and take a higher-level perspective. When your rules authoring is done, what should you do? In this series, we will talk about topics like lifecycle management and testing. Today, let’s cover release management.
What is Release Management?
You are certainly familiar with versioning, which is the ability to keep track of each modification in your repository. Versioning is typically offered out of the box, and does not rely on anyone setting it up, or explicitly creating versions. That way, you can see day-to-day, who modify what, when, and why (if they provided a comment).
Release management takes a higher perspective on change management. When you create a release, you freeze the state of each rule that contributes to the decision. The release is, conceptually, a packaging for your decision, frozen in a certain state. Changes to the project, from that point on, will not be visible in the release.
While each decision management product is different, we believe strongly that products should not create copies of your rules projects. A release should only refer to the manifest of your decision content. It should not duplicate the rules.
Why should you create Releases?
The first and foremost reason is agility. As you deploy changes to your decisions, we expect your rules to improve over time. Unfortunately, unforeseen problems can hide in your decision logic, and slip through your QA efforts. For example, changing a threshold too aggressively could impact dramatically your decline rate. While this is correct in terms of execution, it may not be aligned with your business objectives.
When such a situation occurs, release management allows you to target the prior release with the click of a button. You can revert back to the prior state of your decision, while your team works on improving the decision logic. The execution engine does not need to know which rules have changed and need to be reverted. The execution engine simply loads the configuration you want to substitute.
Related, but slightly different, is the ability to load multiple configurations jointly. For progressive roll-outs, releases make it easy to continue processing the ‘old’ rules for most of your transactions, and the ‘new’ rules for 5 or 10% of your traffic. Once you feel comfortable with the new logic, you can route all transactions to the latest release of the decision.
Finally, there is huge value in transparency. By using releases, you can go back at any point in time to the state of the rules when a given transaction was processed. We have seen the need in case of legal challenge or internal investigation. Whatever the reason might be, releases are always available. As a frozen copy, the rules in a release cannot technically be modified. You can rely that what you see is what executed at that point in time. And you can now leverage all investigation tools to understand how the decision was made.
In conclusion, if you are not using release today, you should. As an added bonus, you will get an easier time tracking changes from release to release with automated ‘diff’ documentation. There is really no reason not to use releases!
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
