The art of simplicity

Azure DevOps (Server) had Mermaid support for a long time. Unfortunately that support was limited to the Wiki functionality. This means that if you had markdown files somewhere else in your repo; for example as part of your readme.md file or an architecture decision record(ADR), any mermaid diagram inside these files was not rendered. Some extensions exists in the Visual Studio marketplace that tried to solve this,  but when using these extensions I noticed that none of these extensions were bug free and all had limitations or caused problems with other features inside Azure DevOps. With the December 2025 release of Azure DevOps, you no longer need a 3th party solution as this feature is finally available. Create a mermaid diagram in any .md file: And the preview tab will now nicely render your diagram: Nice! More information Markdown Syntax for Files, Widgets, Wikis - Azure DevOps | Microsoft Learn Azure DevOps Server Release Notes - Azure DevOps Server & T...

Last week I shared my understanding of how capacity works in Microsoft Fabric. I just hit publish when I got a message that I exceeded my Fabric capacity (again). Time to open the Fabrics Metrics dashboard I introduced in my last post about Fabric and see who is the culprit: I opened the Compute tab and hovered over the top item in the list.  Turns out that Copilot is eating up a lot of my capacity. Whoops! I decided to disable copilot for this data warehouse. Therefore, I opened up a query in the data warehouse and clicked on the Copilot completions item at the bottom of the screen: This opens the configuration settings for my data warehouse where I can disable the completions:   If you want to disable Copilot completely, you can do that at the tenant level :   Remark: If you are still confused on how Fabric capacity exactly works, I found this great post by Tom Keim where he compares CU usage to watts: Just like electricity, where we’re billed by k...

Azure DevOps offers a repository health feature, which allows to monitor multiple metrics that contribute to the health of your Git repositories. If you are using Azure DevOps services, you maybe already know this feature. But with the latest release of Azure DevOps server (December 2025) , it finally arrived on-premise as well. Reasons enough to have a deeper look at it and write this post. Let’s dive in! Why is this feature relevant for my team? Think of your Git repository like a living organism. As it grows with more commits, blobs, branches, and objects, it can become sluggish and unwieldy. Large repositories increase the load on Azure DevOps infrastructure, affecting performance and user experience. Without proper maintenance, your team could face slower clone times, degraded git operations, and even service disruptions. The repository health feature now provides visibility into key health metrics and offers actionable recommendations before problems escalate. Getting t...

Being new to Microsoft Fabric, one of the topics that I found challenging, is how Fabric capacity and especially the throttling works. And what is a better way to structure my understanding than writing a blog post. Let’s give it a try! Remark : If I made some mistakes, please feel free to let me know so I can update this article. What is Microsoft Fabric Capacity? Microsoft Fabric capacity is the compute and storage resources you purchase to run Fabric workloads. Unlike traditional per-service pricing models, Fabric uses a unified capacity model where you purchase Capacity Units (CUs) that power all Fabric experiences including Data Engineering, Data Warehouse, Data Science, Real-Time Analytics, Power BI, and Data Factory. When you purchase a Fabric capacity, you're essentially reserving a pool of compute resources that can be shared across different workloads and users within your organization. This capacity is measured in Capacity Units, which represent the computational...

I promised yesterday that it would be my last post about how we are using Dependency Track. But turns out that there is some confusion and a few people asked me the following question: "How should I organize all these projects?" This is a good question because a well-structured project hierarchy makes the difference between a dashboard that provides clarity and one that creates confusion. In this post, I'll share the project organization strategies we've explored and practical examples you can adapt to your organization. Understanding Dependency-Track's model Dependency-Track organizes work around several key concepts: Projects : The fundamental unit representing a software component. Each project has a name and version. Remark: A project can also be flagged as current. Versions : Projects can have multiple versions representing different releases or deployments. Classifiers : Indicates if the project type is a library, framework, ...

Welcome to the final post in this Dependency-Track series! We've covered what Dependency-Track is and why we started using it , how to deploy it on Azure Container Apps , and how to configure OIDC authentication with Microsoft Entra ID. Now it's time to put it all together by integrating Dependency-Track into our Azure DevOps CI/CD pipelines. In this post, I'll show you how to automatically generate Software Bill of Materials (SBOMs and upload them to Dependency-Track, By the end, you'll have a fully automated vulnerability management workflow that provides continuous visibility into your software supply chain. CI/CD architecture We adopted the following approach for integrating Dependency-Track in our CI/CD architecture: During the CI phase we generate an SBOM as part of the build process using language-specific tools and store it among the other build artifacts During the CD phase , the code is rolled out in multiple environments with approval checks between...