Classic Azure deployments often leave behind orphaned role assignments, creating clutter and confusion. In this post, I explore how Deployment Stacks—tested via GitHub Actions—offer a cleaner, more predictable way to manage and remove role assignments at the subscription level. Includes code, setup insights, and lessons learned.

There is no reason not to switch to Workload Identity Federation for Service Connections in Azure DevOps. Compared to secret-based connections, it offers several compelling benefits:

• Firstly, you eliminate the need for secrets. This means no more manual or automatic rotation of secrets, or worse, being caught off guard when secrets expire unnoticed.
• Secondly, it’s more secure. Secrets used across multiple projects and stored in key vaults or, even worse, in tools like OneNote, are far more susceptible to compromise than the new identity federation approach.

Here is my step-by-step guide on setting up Workload Identity Federation in Azure DevOps. I recommend the manual setup over the automatic one for these reasons:

This post is a techy one. It’s about running git commands in Azure DevOps Releases in order to finalize a deployment job to production.

Let me first describe our scenario:

We use Azure DevOps for code and for deployment. Our branch strategy a simplified Gitflow model, where all the current work is merged to the “develop” branch. The code from the “develop” branch is then built and released to staging environments and production. After a release to Production and regression tests the develop branch needs to be merged into the “main” branch (or “master”). So simply put, the git merge into main is what we mean by finalizing a production release.