how to migrate rules and decision tables in Drools workbench from one environment to another ?

[Sprao]

We have a setup where Drools workbench is deployed in all of our environments with their own local GIT repositories on them. I wanted to know if there is any way I can export and import the rules and decision tables from one git repo in dev environment to similar repo in test environment without causing broken links (along with it some broken hearts:) ) Note that this is the first time organization is using Drools workbench and lot of us here too are novice users on this tool.

What is the migration process in general when using Drools workbench?

[Michael Anstis]

As you know the repositories within the workbench are simply git repositories. Therefore you can clone them, copy out the necessary files into another git repository and commit the changes.

So clone your dev and QA environment repositories, copy the files you want from dev to QA and commit and push to QA. Make sure you include any supplementary files too (Java classes, DSLs and globals mainly, but if you want to author in QA then enumerations too).

I'd have thought you'd probably only want dev to support authoring and QA and PROD to have the KJAR.. in which case you probably don't need a workbench per environment; only maven repositories. Then you'd promote the KJAR from dev to QA and PROD Maven repositories. Dev's Maven repository is provided by the workbench.

6.2.x has the ability to author rules in a dev branch and promote changes to QA and PROD branches which would allow you to potentially run one workbench and publish -SNAPSHOTs for dev, and non-SNAPSHOTs for the other environments.

Feedback on this 6.2.x feature is welcome.

Sent on the move

On 2 Dec 2014 20:41, "Sprao" <sudhaka...@gmail.com> wrote:

We have a setup where Drools workbench is deployed in all of our environments with their own local GIT repositories on them. I wanted to know if there is any way I can export and import the rules and decision tables from one git repo in dev environment to similar repo in test environment without causing broken links (along with it some broken hearts:) ) Note that this is the first time organization is using Drools workbench and lot of us here too are novice users on this tool.

What is the migration process in general when using Drools workbench?

--
You received this message because you are subscribed to the Google Groups "Drools Setup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-setup...@googlegroups.com.
To post to this group, send email to drools...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drools-setup/ecb5233c-5276-4161-8271-864963305deb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sprao]

Thanks Mike. I like your solution #2 better since it requires me to standup only 1 workbench environment :) Currently we have only 2 maven repositories SNAPSHOTS and RELEASES across all environments..in such scenario, can we just use SNAPSHOTS repo for DEV and the publish to RELEASES repo whenever the assets are ready to be migrated to other environments? It is probably a workaround, but do you think it will work?  

[Mark Proctor]

In master we have branch management within the tool now - called “managed repositories”.

The recommendation is you keep all your branches on one machine, but use different maven repositories to give the separation of environments. As the maven repository is just an http file system, you can setup an external job to copy across the jars to your STAGE and PROD environments. Later we hope to add a tool to automate this process, with some form of approval workflow.

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/drools-setup/68e246e8-294a-4f2f-a2d2-0f359c0130ec%40googlegroups.com.