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

3

Hi @javahippie ,
It took a while, but I’ve now made progress and am about to deploy operatondev.open-regels.nl (test/acc) and operaton.open-regels.nl(prod).

Both on the same Azure VM. For now.

The current setup is just Docker with a manual deployment of three isolated DMN’s that are orchestrated together with a single BPMN for combined evaluation.

I’m mainly interested in gaining practical experience with managing changes and/or extensions to the DMN’s and BPMN('s) on the one hand, and the Operaton releases themselves on the other.

I’m very curious about your option 1. However, I have zero experience with and/or knowledge of what you call “Bundling as a Tomcat container, having the DMN files in the resources.”

Can you help me get started with this without it costing you a lot of valuable time?

4

@steven That’s touching a lot of topics. I’d be happy to jump on a call with you, but I wonder if there is a way to better document these different styles of operating Operaton in production for the general public. Maybe this is something that could suit a blog post very well. If you like, you can suggest a date and time for a ~1 hour call? If it’s fine with you, we can also share the call so others can jump in and learn a thing or two, but I’d also be happy to do a 1:1 call for now.

5

@Javahippie, thanks for your suggestion. I really appreciate it.

I propose that I spend some time further improving and optimizing my current setup (see below), and then we schedule a call where others are, of course, welcome. I can then (briefly!) share some of my Docker experiences with realizing dev and prod environments isolated with their own images, databases and proper routing through Caddy on a single VM, and the rest of the time we’re all in your masterclass. :grinning_face:

Update Docker config

It was a real struggle. I started with the Nginx Proxy Manager but couldn’t get it working. I switched to Caddy, and that also took forever before I could conclude that Caddy was routing both my domains to the same container, despite the different names…

A Caddy file with container IP addresses was the solution.

operaton.open-regels.nl {
    reverse_proxy 172.18.0.3:8080
    encode gzip
}

operaton-dev.open-regels.nl {
    reverse_proxy 172.18.0.4:8080
    encode gzip
}

For now, I’m satisfied and can slowly start introducing improvements. The initial configuration I’m running now can be found here.

I will definitely look at the start script arguments later as well

1 Like
6

I’ve just finalized documenting the current infrastructure and will now focus on getting the start script arguments configurable via docker compose.

Overview of the architecture

image
image888Ă—1220 59.6 KB