The art of simplicity

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

In my previous posts, I introduced Dependency-Track and showed you how to deploy it on Azure Container Apps . Now that you have a working instance, it's time to secure it properly by integrating with your organization's identity provider. In this post, I'll walk you through configuring Dependency-Track to use OpenID Connect (OIDC) authentication with Microsoft Entra ID (formerly Azure Active Directory). This integration will allow your users to log in using their existing corporate credentials, enable single sign-on (SSO), and leverage conditional access policies for enhanced security. Why using OIDC with Microsoft Entra ID? Before diving into the configuration, let's understand the benefits of this integration: Centralized Identity Management : Users authenticate with their existing Microsoft Entra ID accounts, eliminating the need to manage separate credentials for Dependency-Track. Single Sign-On (SSO) : Users already logged into Microsoft services can acc...

In my previous post , I introduced Dependency-Track and explained why we chose it to manage our software supply chain security. Now it's time to get practical. In this post, I'll walk you through how we deployed Dependency-Track on Azure Container Apps, including our architecture decisions, configuration choices, and lessons learned along the way. Why Azure Container Apps? Before diving into the setup, let me explain why we chose Azure Container Apps for hosting Dependency-Track. We evaluated several deployment options including Azure Kubernetes Service (AKS), Azure Container Instances (ACI), and App Service, but Container Apps emerged as the best fit for our needs: Simplified Management : Container Apps abstracts away much of the complexity of Kubernetes while still providing container orchestration capabilities. We don't need to manage nodes, clusters, or complex networking configurations. Cost-Effective : With built-in autoscaling and the ability to scale to zero...