8:10 p.m.
Thank you, Steve,
I looked at KnowledgeAgent and KieScanner documentation and looks like this is something
that can help in hot deployment, but not so much in safe proofing.
Here are some basic facts (or misconceptions) that I have gathered so far:
1. KnowledgeAgent and KieScanner are able to dynamically detect changes in the rules (and
other resources) and hot-deploy them to running Drools installation;
2. KnowledgeAgent belongs to Drools 5.X. In 6.X it is deprecated in favor of KieScanner
(which is available starting 6.0.X);
3. KnowledgeAgent transmits changes through monitoring file system for .DRL files or via
HTTP connection to a running Guvnor instance;
4. KieScanner transmits changes through monitoring Maven repository. It appears like old
KnowledgeAgent's ability to transmit individual .DRL files is deprecated;
5. Neither KnowledgeAgent nor KieScanner have a built-in mechanism for error handling, at
least not a sophisticated one. There is no way to perform a rollback if at some point it
becomes clear that a new update is a bad one.
Thanks,
Alex
If you want to hot-deploy rule changes, just take a look at the
documentation on knowledge agents or KieScanner (v6). It's also easy enough to code a
knowledge base reload yourself.
However, you say:
Ideally we would like business users to add or modify rules in Production without
risk of crashing entire rules engine.
Rules and facts are code, so changes could crash your system if written poorly.
Supporting hot deployment does not mean that you don't need to regression test your
changes. All it means is that you can break your system much more quickly than before.
The only way to get around this is to write your own UI, which prevents users from making
any rules or fact changes that 'break' your system. How you achieve that is very
much dependent on what you want users to change and how much time you are prepared to
spend writing automated tests to prevent breaking changes from being deployed.
Steve
12:03 p.m.
New subject: (Hot?) rules production deployment
Pretty much correct.
re. 5 - It depends on what you mean by it becoming clear that a release is a bad one.
I have tended to code up my own knowledge base reloads and check for errors, but I’m
pretty sure that if your rules don’t compile, then neither the KnowledgeAgent nor the
KieScanner will deploy them. If you use Guvnor, then your project will not be built and
packaged if the rules don’t compile.
However, if the problem is that the new rules are just ‘wrong’ within your domain, then
it’s hard to think of any way in which that could be detected automatically, other than by
you yourself writing the validation.
To help with this, I have previously set up a FitNesse server which would load in the
latest rules and evaluate them, ensuring that output expectations are met. However, no
such test suite is perfect. It may be that a change is made which needs a new test to
evaluate it. If that test is not written, then the suite of tests still passes.
Similarly, you can write unit tests for the build. You can deploy to a staging server,
where the rules can be evaluated with as-live data, so that you can regression test the
rules service in isolation from the rest of your application.
Looking at rollback, in one Guvnor-based system, I have the users take a snapshot for each
rules deployment. They then copy that snapshot to an “approved” snapshot. This way,
rollback is just a case of copying the previous version to “approved” and deploying that.
The users are legal and back office operations teams, and they are pretty efficient at
following this process these days.
However, in the end it comes down to things like:
What kind of rule changes do users typically make? i.e. Are they just changing some
numbers in existing decision tables?
Can you trust the users to only make non-risky changes? Guvnor won’t stop them from
altering the structure of decision tables, or adding new non-decision-table rules.
How risk-averse are you?
Steve
On 23 Apr 2014, at 19:10, Pykhtin, Alex <apykhtin(a)ebay.com> wrote:
Thank you, Steve,
I looked at KnowledgeAgent and KieScanner documentation and looks like this is something
that can help in hot deployment, but not so much in safe proofing.
Here are some basic facts (or misconceptions) that I have gathered so far:
1. KnowledgeAgent and KieScanner are able to dynamically detect changes in the rules
(and other resources) and hot-deploy them to running Drools installation;
2. KnowledgeAgent belongs to Drools 5.X. In 6.X it is deprecated in favor of KieScanner
(which is available starting 6.0.X);
3. KnowledgeAgent transmits changes through monitoring file system for .DRL files or via
HTTP connection to a running Guvnor instance;
4. KieScanner transmits changes through monitoring Maven repository. It appears like old
KnowledgeAgent’s ability to transmit individual .DRL files is deprecated;
5. Neither KnowledgeAgent nor KieScanner have a built-in mechanism for error handling,
at least not a sophisticated one. There is no way to perform a rollback if at some point
it becomes clear that a new update is a bad one.
Thanks,
Alex
> If you want to hot-deploy rule changes, just take a look at the documentation on
knowledge agents or KieScanner (v6). It’s also easy enough to code a knowledge base reload
yourself.
>
> However, you say:
>
> Ideally we would like business users to add or modify rules in Production
without risk of crashing entire rules engine.
>
> Rules and facts are code, so changes could crash your system if written poorly.
Supporting hot deployment does not mean that you don’t need to regression test your
changes. All it means is that you can break your system much more quickly than before.
>
> The only way to get around this is to write your own UI, which prevents users from
making any rules or fact changes that ‘break’ your system. How you achieve that is very
much dependent on what you want users to change and how much time you are prepared to
spend writing automated tests to prevent breaking changes from being deployed.
>
> Steve
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3649
days inactive
3650
days old
1 comments
2 participants
participants (2)
-
Pykhtin, Alex -
Stephen Masters