10:21 a.m.
Anyone can tell if Drools supports hot deployment of rules and fact types?
We are using Drools rules (No Guvnor/Workbench), and the whole cycle
Development-Test-Production takes a very long time. Ideally we would like business users
to add or modify rules in Production without risk of crashing entire rules engine. But as
of today, any rule or fact type change is subject to full regression testing, as any other
of our Java code. I tried to experiment with Drools Workbench, but so far it doesn't
look like it can help much with hot deployment. Workbench can greatly streamline the
development and deployment process, but generally speaking, since all Drools boils down to
Java, it is essentially another jar deployment. So, it looks like if we would want to
simplify our production deployments, the only option is to abolish the QA cycle for Drools
jars (which our QA will probably never agree to).
Any ideas?
Thanks,
Alex
7:47 a.m.
New subject: (Hot?) rules production deployment
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
On 21 Apr 2014, at 16:21, Pykhtin, Alex <apykhtin(a)ebay.com> wrote:
Anyone can tell if Drools supports hot deployment of rules and fact
types?
We are using Drools rules (No Guvnor/Workbench), and the whole cycle
Development-Test-Production takes a very long time. Ideally we would like business users
to add or modify rules in Production without risk of crashing entire rules engine. But as
of today, any rule or fact type change is subject to full regression testing, as any other
of our Java code. I tried to experiment with Drools Workbench, but so far it doesn’t look
like it can help much with hot deployment. Workbench can greatly streamline the
development and deployment process, but generally speaking, since all Drools boils down to
Java, it is essentially another jar deployment. So, it looks like if we would want to
simplify our production deployments, the only option is to abolish the QA cycle for Drools
jars (which our QA will probably never agree to).
Any ideas?
Thanks,
Alex
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:42 a.m.
New subject: (Hot?) rules production deployment
Another technique to prevent non-programmers to wreak havoc is to
put them on the leash of a domain specific language (DSL). But developing
a non-trivial DSL is hard work, and you might find that you just spend
your money in a different way. Moreover, anything that's not too
restrictive must, by definition, provide enough leeway to enable
the non-programmers to program nonsense: this won't crash the
system but it sure will annoy the users.
The claim that "our business users write rules" is very frequently
based on them typing, into a spreadsheet or similar, parameters
for a small, limited number of rule templates, which are then
replicated by filling in constant values...
-W
On 22/04/2014, Stephen Masters <stephen.masters(a)me.com> wrote:
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
On 21 Apr 2014, at 16:21, Pykhtin, Alex <apykhtin(a)ebay.com> wrote:
> Anyone can tell if Drools supports hot deployment of rules and fact
> types?
>
> We are using Drools rules (No Guvnor/Workbench), and the whole cycle
> Development-Test-Production takes a very long time. Ideally we would like
> business users to add or modify rules in Production without risk of
> crashing entire rules engine. But as of today, any rule or fact type
> change is subject to full regression testing, as any other of our Java
> code. I tried to experiment with Drools Workbench, but so far it doesn't
> look like it can help much with hot deployment. Workbench can greatly
> streamline the development and deployment process, but generally speaking,
> since all Drools boils down to Java, it is essentially another jar
> deployment. So, it looks like if we would want to simplify our production
> deployments, the only option is to abolish the QA cycle for Drools jars
> (which our QA will probably never agree to).
>
> Any ideas?
>
> Thanks,
> Alex
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
3871
days inactive
3872
days old
2 comments
3 participants
participants (3)
-
Pykhtin, Alex -
Stephen Masters -
Wolfgang Laun