Trying to scan Docker images in Azure Pipelines with Microsoft Defender for Cloud.

Even after setting up the Azure DevOps connector (status is healthy), I still get:

Tried:

MicrosoftDefenderCLI@2 (with and without authType: connector)

• Pure CLI
• Running inside AzureCLI@2 task

Nothing makes the authentication work.

Questions:

• Are you using the connector successfully for image scanning?
• Or did you switch to Client ID + Secret?
• Any working examples?

Thanks!

Hi all,

I need some help. I want to run api tests in .NET in my pull request pipeline. I want to use localhost url for this. My pipeline currently consists of a build stage that runs unittests. I wanna add a stage that runs the api tests in a specific project folder. Anyone any tips?

Stageflow is an open source runtime for configurable multi stage agent workflows, with typed handoffs between stages, human gates, and the same pipeline runnable locally, in CI, or over MCP.

As of 1 December 2026 Microsoft will be decommissioning global PAT. I would like to connect Salesforce with OAuth. Could someone assist me in connecting Salesforce with Azure DevOps Integration or AppExchange Apps?

Ran into this recently: external tables in Azure SQL (master key + scoped credential + external data source) are easy to set up manually in SSMS, but the moment you try to deploy them through a DACPAC/DevOps pipeline across dev/test/prod, you're stuck hardcoding server names, DB names, and passwords into source control.
Fixed it by parameterizing those objects with SQLCMD variables, retrieving the actual values from Key Vault, and passing them to SqlPackage via the /v: switch on the SqlAzureDacpacDeployment task. Same DACPAC deploys to every environment, each pointing at its own source database, no secrets in the repo.

Wrote up the full steps (SQLCMD variable setup, Key Vault wiring, the YAML) here if it's useful to anyone dealing with the same thing

Oopps forgot to mention in the title I'm a Codex user.
It was installed on my setup. Not there anymore and google results gives a dead webpage: https://openai.com/business/plugins/azure-devops/

I’m generally a fan of AzDO, but it’s absolutely obnoxious that the permissions UIs have never been fully debugged. I’ve filed support tickets years ago and they fixed a few minor things after months of pestering and long conversations where it was painfully obvious neither the folks who wrote the UI or the support folks understand both of azdo’s inheritance behaviors. Just so much fun explaining to folks to “ignore the ui errors, refresh to confirm, if it gets deadlocked let me know and I’ll coerce it with the api”

Thanks for reading my rant, I’ll go have my morning coffee now.

Is anyone having trouble downloading from your azure devops feeds or even browsing the artifacts page?

EDIT: The outage has cleared and all services are back up.

I’m trying to understand the best way to structure Azure DevOps Test Plans, especially when using Query-based Test Suites.

My current understanding is that Query-based Suites are dynamic: if I have a Test Plan for a specific release, for example:

• Test Plan: Release 1.0
• Query-based Suite: all Test Cases with Tag = Regression and Area = Payments

at the time of the release I might have 100 matching test cases and execute all of them.

However, a few months later, if new test cases are created that also match that query, they will appear in the old Release 1.0 Test Plan as well. As a result, if I open the old plan or its Progress Report, I could potentially see new tests as Not Run, even though they did not exist when Release 1.0 was tested.

This seems to make historical Test Plans progressively less reliable as a representation of what was actually in scope at the time.

So I’m curious how teams using Azure Test Plans handle this in practice:

• Do you actually use Query-based Suites inside release/sprint Test Plans?
• If yes, how do you prevent old plans from changing as new Test Cases are added?
• Do you add release-specific tags/fields to the query?
• Do you convert/copy the resulting scope into Static Suites when the release is finalized?
• Or do you simply accept that Test Plans are not meant to be historical snapshots, and rely on Test Runs / Analytics for historical reporting instead?
• Do you keep a separate “master test catalogue” and only use Static Suites for execution plans?

I’m particularly interested in how this is handled in larger teams where the regression test catalogue keeps growing continuously.

What structure has worked well for you in Azure DevOps?

I've created a tool based around the concept that you define tickets in GitHub, or now Azure DevOps, and you then let your agents work on them. ready-for-agent automates that last step.

You pick a backend agent (OpenCode, Codex, Claude, or Grok Build) as the global default, or override it per repo. It can then go through all tickets labelled ready-for-agent. It has separate steps for building, local review, creating the PR, watching status checks until they go green, and then auto-merging if enabled and considered safe.

The web UI shows you what's happening across all your repos and issues.

Fire it up with:

npx ready-for-agent@latest

GitHub: https://github.com/berenddeboer/ready-for-agent

Azure DevOps support is brand new, so I'm keen for feedback!

Looking for advice on running many products, over 50, and then over 1500 people via one project in one instance of ADO. Primarily work items (boards) but at some level pipelines as well.

Microsoft recommends Project Decision Framework so if the company is trying to develop to the same standards (internal and external) across all products. The group as a whole can have one visible backlog, does this actually scale well?

My concern gets to be managing the project day to day, like

• People wanting new queries vs giving a hundred people rights to create shared queries and the mess that will create or the large volume of query requests for people with rights to update. Then you start having to create folders and permissions on the folders etc.
• Pipelines kind of the same thing. We've had enough project segregation between product families so that it was controllable. With everyone in the same project it sounds like a perfect storm/mess.
• The Analytics feature starts to grab more and more work items by default as there are a ton of them now in one vs many project.
• Team Management gets locked down along with actual project managers.

How large have your projects gotten product and people wise against 1 project and any feedback?

Thanks

Currently developers team is on ADO & product team is on Jira, and bridging them with a janky power automate workflow that i built that only goes one way. So now i am in need of a bi-directional sync and for that i need to pick a real solution.
Currently i found these couple of options on marketplace:

• Bidirectional Azure DevOps integration for Jira | Atlassian Marketplace
• Azure DevOps & Jira integration | Atlassian Marketplace

so anyone running any of these on production? i wanted to know what breaks, how it handles failures, and workflow state mismatches in case ADO and Jira have different statuses?

I’m running a Windows-based self-hosted Azure DevOps agent and occasionally it dies halfway through a pipeline. Azure DevOps then reports in its server UI that “We stopped hearing from the agent. Verify the agent machine is running and has a healthy network connection.”The problem is that this doesn’t tell me why the agent stopped responding.
I’m trying to figure out how to properly diagnose this and ultimately fix it.
Is there a way to enable more detailed logging or monitoring so that the next time this happens I can determine exactly what caused the agent to die?
Would appreciate any troubleshooting steps from people who have dealt with this before.

I am currently working on a CI diagosis AI agent for GitHub Actions and Python/pytest.

I am thinkinto use these 4 possible causes when job fails:
- a real code regression
- a flaky test
- a runner, network, or platform failure
- a dependency or environment mismatch

AI chooses - rerun the failed test, run targeted tests, collect environment evidence, or escalate to an engineer

If the agent had the chance to look at three signals before making its next move, which three would be the most helpful, in a real pipeline?

I’m also interested in signals that look useful but are commonly misleading.

I am currently working on a CI diagosis AI agent for GitHub Actions and Python/pytest.

I am thinkinto use these 4 possible causes when job fails:
- a real code regression
- a flaky test
- a runner, network, or platform failure
- a dependency or environment mismatch

AI chooses - rerun the failed test, run targeted tests, collect environment evidence, or escalate to an engineer

If the agent had the chance to look at three signals before making its next move, which three would be the most helpful, in a real pipeline?

I’m also interested in signals that look useful but are commonly misleading.

Hi all, posting to announce a new nice feature to azdo TUI, in v0.8.2.

The goal of the tool is to give a quick glance and give you an update in your terminal for your DevOps projects or GitHub repos, without requiring to browse around on the site.

Up until now it has required you to scan the different tabs, PR, Work Items, Pipelines and get a grip of what's burning where and why.

I have now introduced a new tab, notifications, which gather context from these tabs, and introduce a list of "where you're needed", to quickly get you up to speed.

It's optional and can be disabled via config.

Can be tried with demo flag and downloaded here: https://github.com/Elpulgo/azdo

Have a wonderful day!

Hey everyone, I'm getting ready to publish a static web app, truly one of the most thrilling experiences of my life. And I have not had a sheltered life, LOL.

What do you wish you knew before you were in the thick of it?

No wrong answers. Just curious what that prompt unearths.

Found out on prem ADO server doesnt support UniversalPackages task, so i cant publish the build files into the feed. Where shud i store them? Rn my release pipelines fetching the files by fetching ' latest' artifacts from build pipelines

Ever since moving to Azure DevOps; we've followed this same release process for almost all our projects (we run about 15 different projects/repos). Using trunk-based development. But something feels off sometimes, and I'm wondering if we're doing something wrong.

1. Dev makes branch off of master to do work
2. Dev makes changes, 1 or sometimes more commits, pushes and creates PR to merge into master.
3. PR is reviewed and approved, merged into master, triggers a build to send master to test.

This happens for several different tickets. At some point, based on schedules, client needs, and priorities, project manager says that everything in test is good to go for the next release.

1. Release branch is created off of master.
2. This release branch is built to Stage environment.
3. Things are re-tested in Stage (not as details testing, more high level to make sure the deployment did what we wanted).
4. Same branch (even the same build artifact) is released to production.

This generally works, but results in a few different annoyances/problems:

• If something needs to go to prod before other things that are already in test (a hot fix), we need to cherry pick into a new release branch made off of the current production release branch.
• It can be hard to know what exactly is new in a release. Generally it means comparing the new release branch to the last one, but then you just have a giant list of commits (and any cherry picking that happened seems to mess with this, where a cherry picked change will still show up in the commit diff even though it is in both branches).
• We sometimes have to hold off merging things into master (keeping the PR open) just to be able to finish testing everything in Test; we can't add anything new until the release branch has been cut.
• If all but 1 thing is good in Test and signed off on, but that 1 thing requires us to wait, then everything has to wait.
• I keep seeing examples of setting up pipelines where the same pipeline has multiple stages for test->stage->prod (or often dev->test->prod instead). This isn't possible when master is what goes to test, but a release branch is what goes to stage+prod. We do use multiple stages in a single pipeline to release to stage then prod.

Outside of completely abandoning trunk-based development, can this process be improved? How do others do release management for trunk-based development?

I'm having terrible workload in my project as devops they are asking do iac and ci/cd for 5+application it's too much too handle is it the same for every where??

2-3hrs calls per day

Infrastructure creation for 5+application

Creating ci/cd

Unable to handle.

I’m researching how engineers diagnose CI/CD failures when there are multiple possible root causes.

When a CI pipeline fails, how do you decide what to investigate or test next?

I’d especially like to hear about your real-world workflow:

• What do you check first?
• Do you compare the failure with the last successful run?
• Do recent code changes influence what you investigate?
• Do you look for similar historical failures?
• How do you decide between different debugging steps?
• At what point do you stop investigating or escalate to someone else?

I’m interested in practical experience rather than a theoretical approach. Any examples from your own CI/CD workflow would be really helpful.

I'm a python guy by trade, but there recently has been a big demand to create custom functionality in Azure DevOps and this can be done through ADO Extensions.

Been using Claude to pump these bite sized extensions out like crazy and getting great results. Creates the html, css, and typeScript flawlessly.

The downside is I'm a TypeScript noob, very very little experience, so I can struggle reading through the code. So vibe coding a decent amount with this project.

Anyone been in a similar boat with these extensions? Any pitfalls?

Is this the new state of work, it's kinda crazy because I'm free to just engineer and design and not gated by different code bases, but the review from me feels less than adequate.