DTAP for Operaton

Operating/Hosting Operaton
1

After recently getting to know Operaton, I am already busy with the journey of discovery and close to an actual implementation in the municipality of Heusden in the Netherlands.

The daily findings and experiences can be followed in Slack.

I will post this message here.

It concerns the setup of a DTAP for Operaton. I want to have a nice DTAP for Operaton shortly after the summer along the lines of:

  • operatondev.open-regels.nl (Development)
  • operatontest.open-regels.nl (Test)
  • acc.regels.overheid.nl (Acceptance)
  • regels.overheid.nl (Production)

I still have to figure out what a good naming convention is for that and how we are going to realize the CI/CD around it. Last but not least, there are many other tools besides Operaton that follow the same DTAP.

Suggestions, tips and recommendations are welcome.

2

Hi @steven, interesting topic!

In the past, I had good results with treating Operaton applications like “normal” Java applications, because I believe this is one of the strenghts in opposition to “all in one” BPM solutions.

I don’t know much about your usecase, e.g. if you change DMN on the fly, or if every DMN change is part of a release process. I had better experience with the second approach, and have seen many people break a prod system with DMN changes. I understand, that DMN is your focus?

I think there are two ways of doing it:

  1. Bundling an Operaton Application with Spring Boot or as a Tomcat container, having the DMN and BPMN files in the resources. This way, you can follow a classic Java test lifecycle, Integration Tests, maybe manual tests and stage the changes. This would deploy a new application with an embedded engine every time, only keeping the data in the database inbetween. Most importantly, testing in an “Acceptance” environment with the same Diff you would have in production, simulating a release from version 1.x to version 1.y and so on. This should be done with running instances and existing data, to avoid nasty surprises on production
  2. Having similar Operaton instances on all environments, and only staging the DMN definitions across those systems. This is a little more finnicky, as you have long-living systems and need to make sure that all of them are configured equally all of the time

I’m not sure if this helped, but I’d be happy to continue the conversation if you have remarks, questions or objctions