Drools Tutorial Series Part 2: Deploy Drools to Production
In Part 2 of our Drools tutorial series, we take a look at the architecture, testing, and CI practices needed to run Drools in production.
Most Drools tutorials stop at authoring: how to write a rule, which condition does what, etc. We’re going to jump straight in to what it takes to get Drools into production!
Repository layout and modularization
Start by organizing a repository that separates concerns:
-
rules/— DRL files and decision tables grouped by domain -
models/— shared domain objects and DTOs -
tests/fixtures/— example input and expected outputs -
ci/— pipeline scripts and deployment manifests
Group rules into logical modules (KIE modules) that can be versioned independently. Smaller, focused modules reduce risk when changes are promoted.
Unit testing rules
Treat rules like code. Use the Drools test harness or JUnit to exercise rules with fixture inputs. Keep tests small and descriptive: one business intent per test.
Example (JUnit snippet):
// example: verify eligibility rule
KieServices ks = KieServices.Factory.get();
KieContainer kc = ks.getKieClasspathContainer();
KieSession ksession = kc.newKieSession("ksession-rules");
Policy policy = loadFixture("fixtures/policy-eligible.json");
ksession.insert(policy);
ksession.fireAllRules();
assertEquals("APPROVED", policy.getDecision());
Automated tests reduce regressions and make refactors safe.
CI/CD pipeline patterns
Pipelines should run unit tests, integration tests, and package artifacts that are deployable (KJARs, container images, or OSGi bundles depending on your runtime).
A minimal pipeline:
- Checkout code
- Run lint & unit tests
- Build KJAR (Maven/Gradle)
- Run integration tests against a local KIE server or embedded runtime
- Package artifact and push to artifact registry (or build container)
- Promote to staging and run smoke tests
- Promote to production with canary/staged rollout
Keep rule changes paired with tests and a clear changelog entry in the PR.
Runtime choices and deployment
Common runtimes:
- KIE Server: suited for centralized rule services and multi-tenant setups
- Embedded JVM: good for microservices where the rules are packaged with the application
- Containerized KIE: combine KIE Server with orchestration for scalability
Pick a model that matches your operational constraints. For many teams, containerized KIE with a simple REST wrapper provides an easy deployment surface.
Safe change patterns
- Canary releases: route a small percentage of traffic to the new ruleset and compare outputs
- Staged promotion: promote artifacts through environments with automated checks
- Versioned rulesets: always keep the prior version available for quick rollback
- Feature flags: gate high-risk changes with a toggle so behavior can be turned off quickly
Observability and alerts
Instrument both system and business metrics:
- System: rule evaluation latency, error rates, queue depths
- Business: decision distributions, approval rates, score histograms
Create alerts for sudden shifts in decision distribution — these are often early signs of broken assumptions.
Example checklist before deploy
- All unit tests pass and have high coverage for edge cases
- Integration tests validate end-to-end flows
- Artifact built and versioned in registry
- Staging smoke tests passed
- Canary comparison thresholds defined and monitored
- Rollback plan documented in the release notes
Conclusion
Productionizing rules is an engineering problem as much as it is a modeling problem. Invest in modular repos, tests, CI/CD, and observability. Those investments turn rules from fragile experiments into reliable decision services.
Be sure to subscribe to get notified of future guides.
Learn more
Explore our Fusion Platform which can get you up and running with production Drools in minutes.
