[rules-users] (Hot?) rules production deployment

[Pykhtin, Alex]

Thank you again, Steve.



We need to make all kind of changes to the rules, however, small changes are more frequent than significant ones. So, every time we are deploying a new rule, there is a risk of it either not compiling or failing properly follow business logic.



We can trust users with any changes, however, moving the code to production is a big deal. This should be vetted by an authority figure, and there must be a simple and transparent rollback plan.

Yes, we want to be very risk-averse.



Ideally, we would like to have:

1.  A staging environment where automation tests are run;

2.  A change can be deployed to production only if all automation tests have passed;

3.  Some kind of administration console from which a change can be manually deployed to production (via uploading to production Maven repository or in some other way);

4.  Production Drools system picking up new changes without interruption of service;

5.  Production console function allowing a one-click rollback of a recent change;



Alex



P.S. Sorry, it looks like I have not mastered proper replying to a forum thread.





> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140424/3f33aa0f/attachment.html