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).

[Gerhard-K]

Hello @y_buccellato ,
Thank you for reaching out.
I'm the product manager responsible for the SDLC observability templates and guides.
As @t_pawlak explained, Monaco is just one of the tools we described in the step-by-step guide for automating config setup. We're already working on Terraform examples for Azure DevOps. You’ll see that we’ve added Terraform examples for GitHub and GitLab to our sample repo.
However, these (Terraform, Monaco) are just two ways to set up, pull in, and deploy the dashboard to gain insights into your pipelines.

We haven’t built the data load step yet because we’re still testing it and gathering feedback to see whether the data model for SDLC events (https://docs.dynatrace.com/docs/shortlink/semantic-dictionary-software-development-lifecycle-sdlc-ev...) suits most users. It’s key for us to build in-product guides that work well for the intended use. With the samples, we stay as flexible as possible for the moment; at the same time, we're aware of the need for a proper in-product guide.

If you have feedback on the SDLC event types or the visualizations we’re providing, we’d appreciate it if you could share your thoughts.

[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

[rgarzon1]

Hehe, the main problem is: what is actually 'reasonable' to DT? Even if you submit an idea, they don't take the time to explain why it's not feasible. It’s a roulette. I work with Dynatrace daily, but frankly, I’m just watching the 'failover' happen while other vendors rise up.

[Gerhard-K]

Hey, @rgarzon1 

Thanks for sharing your thoughts on this. As the product manager for SDLC observability, I’m responsible for our guides, including the one for Azure DevOps pipeline visibility.

Rest assured, we’re taking your feedback seriously and see the growing demand for an in-product guided solution for ingesting the needed SDLC events.

As you mentioned in another reply, the samples and guides are meant to show what’s possible so users don’t have to start from scratch.

As you correctly outlined, webhook setups on Azure and other pipeline tools are usually very complex, so we’re trying to find the optimal point for most users. That’s why we started with templates and an SDLC event data model (https://docs.dynatrace.com/docs/shortlink/semantic-dictionary-software-development-lifecycle-sdlc-ev...) to see if they suit our users. We’d love to hear your feedback on the model and the pipeline use case!

One option I want to mention is the https://github.com/dynatrace-wwse/cicd-observability-app from our solutions engineers. It is built on top of our SDLC event data model and offers another way to set up and visualize pipeline data. Please let us know what you think, and feel free to raise issues in the GitHub repo.
Please consider: This app is not an officially supported Dynatrace app, but from our solutions engineering colleagues to simplify certain use cases.

Happy to discuss further use cases for SDLC observability and potential enhancements!

Best,

Gerhard