Hi everyone,
We’re currently evaluating Dynatrace Monaco as our Configuration-as-Code solution for managing automation workflows, and overall it looks promising. Monaco is frequently recommended by the Dynatrace team and community for managing workflows as code at scale.
However, we’ve run into a concern that may become a maintainability challenge as workflow adoption grows.
The challenge
Many of our workflows contain:
- Multiple tasks
- JavaScript actions
- Conditional routing
- Error handling
- External integrations
When exported and managed through Monaco, the workflow appears as a large serialized object, with JavaScript embedded within the workflow definition.
This raises a few concerns:
- Difficult code reviews in Git
- Large diffs for relatively small changes
- Merge conflicts when multiple developers modify the same workflow
- Reduced readability compared to maintaining code in separate source files
- Challenges applying standard development practices such as linting and unit testing of workflow logic
Questions for the community
For teams actively managing Dynatrace workflows as code:
- Are you maintaining workflow definitions directly in Monaco-exported YAML/JSON?
- How do you review workflow changes in pull requests?
- Do you keep JavaScript task code in separate source files and generate the Monaco artifacts during CI/CD?
- Have you adopted an “Infrastructure as Code” pattern where Monaco artifacts are generated rather than manually edited?
- At what scale (number of workflows/developers) did workflow maintainability become a concern?
Looking for real-world experiences
I’m particularly interested in hearing from teams that manage:
- Dozens of workflows
- Multiple contributors
- Complex workflow logic
- Git-based deployment pipelines
Has the workflow export format been a significant challenge, or is it generally manageable in practice?
Any examples, lessons learned, or recommended repository structures would be greatly appreciated.
Thanks!