SDLC Azure Dev Ops - Monaco prerequisite

[y_buccellato]

Hello Community,

seen Dt official doc for Azure DevOps SDLC integration.
What I really don't understand is: why do I need the Monaco dependency?

Isn't it a dependecy that we can avoid?

Regards,

Yann

[t_pawlak · Accepted solution]

Hi Yann,

In that tutorial, Monaco isn’t required for “observing Azure DevOps” as a concept — it’s mainly the delivery mechanism Dynatrace chose for the sample package (dashboards + OpenPipeline SDLC normalization config) so you can apply it repeatably and (optionally) keep it in Git as “observability-as-code”.

Monaco is mentioned as a prerequisite, because the tutorial isn’t only “send webhooks to an ingest endpoint”. It also sets up (and possibly merges with your existing) OpenPipeline configuration for SDLC events and deploys the dashboards that visualize those events. Monaco provides:

Deploy + download + merge workflow for OpenPipeline configs (especially if you already customized ingest sources/routes/pipelines).

Repeatability across environments (dev/test/prod / multiple tenants) via a manifest.
So, monaco is optional, but Dynatrace uses it to make the tutorial a one-command, reproducible deployment rather than a long “click/API call” walkthrough

[y_buccellato]

Thank you for clarifing.
I do have some follow up curiosity: I see the procedural step by step article on GitHub which is totally fine and well documentend and while going over it I have some kind of tought like "Why didn't they automate this process dirctly into the Opepipeline mechanism?" Like if you want to process well known data that Dynatrace have studied already for their client should there be a pop-up asking "Hey were you about to ingest SDLC for AzureDevOps? If so here you have all the processor rule added :)"

I'm just curios about the limitation the team has encounred in modeling a more user frienly approach (altought the currect is already fine but goes in the general direction that Dynatrace is more for platform experts than newbie).

[rgarzon1]

Monaco is simply the delivery mechanism used to push the filtering and mapping rules, and yes, we can avoid it

To be clear, I am not reporting a bug, but rather highlighting a limitation in the architecture.

Honestly, the current implementation for Azure DevOps leaves a lot to be desired. Azure’s webhook architecture is inherently complex (heavily nested information often wrapped inside links), but the real issue is how Dynatrace forces us to handle it.

Instead of providing native, OOTB ingestion to interpret these events, we are essentially doing the integration work that the product should ideally handle out of the box.

It’s impossible not to compare this with other observability solutions on the market, where this integration is seamless and significantly more dev-friendly. Here, it feels like we require a disproportionate amount of engineering effort simply to obtain standard SDLC metrics. While it is certainly possible to achieve (as shown in the documentation), the configuration experience is far from modern.

[y_buccellato]

Very interesting what you are saying. Was drilling down and having the same feeling. (to be honest it is better than starting from scratch anyway)

[rgarzon1]

Oh yes, it’s better than starting from scratch, but the effort involved is simply not what you expect from a top global app.

[y_buccellato]

ouch ouch 😄
I'll experience it and come back with my feed to the person in DT which manage this. Maybe they find room for improvement.
And i think you should raise an idea if you haven't already. Did more than a couple of time and DT actually does stuff if it is at a reasonable reach for a reasonable goal.

Regards my friend