[rules-users] Continuous deployment of rules/vetoing changesets

[Michael Anstis]

This might provide some useful information:
https://community.jboss.org/wiki/PublishDroolsArtifactsFromAProductionEnvironment

On 28 June 2012 10:15, Stephen Masters <stephen.masters at me.com> wrote:

> One option:
>
>
>    - Point your production environment at a LIVE snapshot (or whatever
>    you want to call it) instead of LATEST.
>    - Point your CI build at LATEST.
>    - On successful completion of the test suite, create a new LIVE
>    snapshot.
>
> That way, you can always see the current live version of your rules in
> Guvnor, and diff them if you need to.
>
> Steve
>
>
>
> On Jun 27, 2012, at 03:20 PM, Gustaf Cele <gustaf.cele at databyran.se>
> wrote:
>
> Hi Wolfgang!
>
> A staging area sounds like a good idea. Would something as simple as this
> work?
>
> KnowledgeAgent stagingAgent = connectToGuvnorAndStartPolling();
> KnowledgeBase productionKnowledgeBase = ...;
> stagingAgent.addEventListener(new DefaultKnowledgeAgentEventListener() {
> @Override
> public void beforeChangeSetApplied(BeforeChangeSetAppliedEvent event) {
> if (allTestsPass()) {
> // copy rules from stagingAgent to productionKnowledgeBase, somehow
> }
> });
>
> ... and in that case, how would I go about the copying part? Is it safe to
> just save the reference from stagingAgent.getKnowledgeBase() if the agent
> is configured with drools.agent.newInstance=true?
>
> /g
>
> -----Original Message-----
> From: Wolfgang Laun [mailto:wolfgang.laun at gmail.com]
> Sent: den 27 juni 2012 15:45
> To: Rules Users List
> Subject: Re: [rules-users] Continuous deployment of rules/vetoing
> changesets
>
> Have you considered using a "staged" approach?
>
> Rather than forwarding LATEST right into production, have one listener
> move it into the staging area or not - depending on the tests. The
> production side listener(s) are directed onto the staging area.
>
> -W
>
>
>
> On 27/06/2012, Gustaf Cele <gustaf.cele at databyran.se> wrote:
> > Hi,
> >
> > I have a Guvnor server (5.4.0.Final) which provides rules to a client
> > (which itself is an EJB server app) using KnowledgeAgents to get hold
> > of rule updates. The knowledge agents are started with changeset XMLs
> > on the classpath which point at my Guvnor instance.
> >
> > The KnowledgeAgents are set up thus:
> >
> > ResourceFactory.getResourceChangeNotifierService().start();
> > ResourceFactory.getResourceChangeScannerService().start();
> > KnowledgeAgent knowledgeAgent =
> > KnowledgeAgentFactory.newKnowledgeAgent(agentName);
> > knowledgeAgent.monitorResourceChangeEvents(true);
> > Resource resource =
> > ResourceFactory.newClassPathResource(changeSetResourcePath, getClass());
> > knowledgeAgent.applyChangeSet(resource);
> > ResourceFactory.getResourceChangeNotifierService().start();
> > ResourceFactory.getResourceChangeScannerService().start();
> >
> > And the changesets look like this (xsd stuff removed for brevity):
> >
> > <change-set>
> > <add>
> > <resource username="ruleclient" password="hunter2"
> > basicAuthentication="enabled"
> >
> > source="
> http://guvnorhost/drools-guvnor/org.drools.guvnor.Guvnor/package/my.package/LATEST
> "
> > type="PKG" />
> > </add>
> > </change-set>
> >
> > As you can see, we use LATEST because we want continuous deployment of
> > our rules. Change a rule, build the package, and have the connected
> > KnowledgeAgents updated with the new rule. This works very well - a
> > bit too well, unfortunately. We have a comprehensive test suite, and
> > every now and then, you'll check in a rule that breaks a test. We want
> > to prevent any changes to our rules from being propagated to the
> > clients until all the tests succeed, and this is where we're stuck.
> >
> > We've tried using a KnowledgeAgentEventListener which throws an
> > exception when it detects test failures:
> >
> > public class VetoListener extends DefaultKnowledgeAgentEventListener {
> > @Override
> > public void beforeChangeSetApplied(BeforeChangeSetAppliedEvent
> > event) {
> > if (!allTestsPass()) {
> > throw new RuntimeException("tests failed, not applying
> > change set");
> > }
> > }
> >
> > boolean allTestsPass(){
> > // Get test results from
> >
> ${guvnor_url}/org.drools.guvnor.Guvnor/package/my.package/LATEST/SCENARIOS
> > // and check if there were any failures
> > }
> > }
> > // Usage:
> > knowledgeAgent.addEventListener(new VetoListener());
> >
> > This does prevent the new changeset from being applied, but it also
> > seems to kill the thread polling for new changes entirely. Restarting
> > the ResourceChange{Scanner,Notifier}Services doesn't help.
> >
> > I've also tried modifying the event's changeset (I know you
> > shouldn't), but it doesn't stop the changes from being applied:
> >
> > public void beforeChangeSetApplied(BeforeChangeSetAppliedEvent event) {
> > if (!allTestsPass()) {
> > event.getChangeSet().getResourcesModified().clear();
> > // ... and clear all the other collections you can get
> > from
> > event.getChangeSet()
> > }
> > }
> >
> > So, what I wonder is if there is any way of preventing a changeset
> > from being applied to a KnowledgeAgent's knowledge base when there are
> > failing test scenarios, but which applies updates as soon as all tests
> > succeed? More generally, I'm looking for something with fewer manual
> > steps than run tests-make snapshot-publish, and in particular I want
> > to ensure you never publish a package when there are tests failing,
> > and it should preferably not require any changes outside of Guvnor to
> > get out new rules to the client app. Any ideas?
> >
> > Thanks in advance,
> >
> > /g
> >
> >
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120628/9a52f618/attachment.html