Hi Ansgar,
Thanks for the feedback. I've actually adopted that exact same workflow for Drools
Expert stuff specifically (except using Jenkins or Bamboo instead of TeamCity). I worry
it might get trickier when Guvnor gets introduced, though. Guvnor is a great tool, but
its functionality overlaps with some very common canonical tools like SVN, Git, Jenkins,
JUnit, etc. It's effectively its own IDE, SCM, Testing Environment and CI so
we're looking for ways to tame those components to be secondary systems so our
canonical tools can remain in place. We also want this to all be seamless for our
business developers, so any form of automated sync would be strongly preferred.
I should also mention that our choice of using Guvnor for this particular project is
mostly motivated by jBPM. The jBPM Process Repository and console seem pretty closely
tied to Guvnor:
http://docs.jboss.org/jbpm/v5.2/userguide/ch15.html
...but perhaps I should sanity-check that assumption as well. Are there reasonable
alternatives for using jBPM (process repo and console) without Guvnor?
--
Build Smarter Software.
Spantree Technology Group, LLC
813 W Randolph St, Suite 301, Chicago, IL
email: cedric(a)spantree.net (mailto:cedric@spantree.net) | phone: 773.359.3865
(tel:773.359.3865)
On Wednesday, October 3, 2012 at 5:04 PM, Ansgar Konermann wrote:
Hi,
we use drools for mortgage risk assessment and use TeamCity for continuous integration of
rules.
Our source code is *.drl (no DSL or processes yet). Rules get unit tested (TestNG),
compiled into binary packages and some integration tests run against each of these
packages. If all is good, we perform an ordinary maven release of the rules. They get a
version number just as any other maven artifact and get deployed to a maven repository
manager (Nexus OSS) and our packaging/deployment tool pulls them from there just before it
needs them.
We don't use guvnor at all (we have a very developer-centric rules-authoring/rollout
process) and perform rule compilation with a maven plugin (
http://passion.forco.de/node/34 ). It does not need any running guvnor instance, but uses
drools' public rules compilation Java API.
If you want to know more details, or have questions, please let me know.
Best regards,
Ansgar
Am 03.10.2012 23:27 schrieb "Cedric Hurst" <cedric(a)spantree.net
(mailto:cedric@spantree.net)>:
> I'd like to get a quick sanity check on best practices...
>
> I'm working on a project where, by policy, all assets (including drl's,
bpmn
> files, etc) must be built, tested and packaged by a Jenkins server. Rule
> assets are structured within a project that also includes non-rule assets.
> As is quite common, the primary system of record for these assets is an SCM
> like svn or git, and that's what our Jenkins box talks to.
>
> However, for the rule stuff specifically, we're also using Guvnor's
> drools-repository to package the assets into a knowledge base, which is
> referenced jBPM's process engine in the runtime. The plan is to have
> several Guvnor environments running with parity to development, QA, UAT and
> production setups. However, we're having a very hard time figuring out how
> best to sync our rule assets to these various repositories as part of an
> automated release.
>
> To the best of my understanding, rule assets are deployed to a Guvnor
> instance file-by-file via WebDAV. One can also upload JARs for POJOs, but
> DRLs, BPMN, DSL files need to be synced individually. Is this the case?
> And, if so, how do other groups handle continuous integration and deployment
> of assets coming from external SCMs?
>
> Btw, I came across aware of a Maven plugin which seems to do this sort of
> piece-by-piece deployment:
>
>
https://github.com/awaterma/drools-guvnor-plugin
>
> So we could certainly port this sort of functionality to our own build
> toolchain, but it seems like a lot of work so I'm hoping for a better way.
>
>
>
> --
> View this message in context:
http://drools.46999.n3.nabble.com/continuous-integration-of-rule-assets-v...
> Sent from the Drools: User forum mailing list archive at
Nabble.com
(
http://Nabble.com).
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org (mailto:rules-users@lists.jboss.org)
>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org (mailto:rules-users@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/rules-users