Managing Conductor DSL Assets

[taoj-action]

We are planning to use Conductor to support thousands of customers, and each of them could have hundreds of workflow with multiple versions written in Conductor DSL. We could store all of those workflows into Conductor and treat Conductor as Workflow Repo. Many of those workflow DSL may not work at all, and we only tag the one working as active workflow.

• What's the good practice of managing a large amount of Conductor DSL assets?
• Shall we treat DSL assets as code?
• Should we manage DSL assets in different storage solutions such as gitops and only load a few working versions into Conductor instead?

Thanks!

[apanicker-nflx]

What's the good practice of managing a large amount of Conductor DSL assets?

Conductor does not have a recommended practice for managing the DSL assets. This is an area of improvement that we would want to focus on in the future.

Shall we treat DSL assets as code?

Yes, DSL assets can be treated as code, however, version control would best be achieved outside of Conductor.

Should we manage DSL assets in different storage solutions such as gitops and only load a few working versions into Conductor instead?

Since Conductor does not have a practice for version tracking of assets and considering this usage Many of those workflow DSL may not work at all, and we only tag the one working as active workflow. it would be best to use a storage solution like gitops to manage these.