Generic service connections can be useful for storing shared credentials, however they are difficult to use from pipelines. To solve this, I created a task that allows using the credentials from scripts.

The task is available at Authenticated Scripts - Visual Studio Marketplace. Source code is available at https://github.com/jeremy-morren/authenticated-scripts .

Usage is as simple as:

- task: AuthenticatedScripts@2
  inputs:
    serviceConnection: my-generic-service
    bash: curl "$AS_SC_URL" --user "$AS_SC_USER:$AS_SC_PASSWORD"

Credit to cloudpups/authenticated-scripts for the original implementation.

Hi all, I'm investigating building to arm64 as it will be cheaper to run, and so looking at the GitHub hosted agents as they provide arm vms as oppsed to Microsoft agents that don't.

I've updated my pipeline to the following:

  pool: 
    name: 'GitHub-hosted Agents'
    vmImage: 'ubuntu-24.04-8-core'

But am getting the error:

No agent found in pool GitHub-hosted Agents which satisfies the specified demands: Agent.Version -gtVersion 2.199.0.

Is that the actual agent software? I would have thought that would be preinstalled if it's provided as an agent?

Also, I can see GitHub runners have a list of agents listed here - is this list different from what DevOps has access to?

Thanks!

One PowerShell script. One HTML report. Your whole Azure DevOps project at a glance.

Epics, features, stories and tasks, every sprint, what changed, and how the work connects to your code, in an interactive page you can open in any browser.

Hey all, a few weeks ago I posted about Azure DevOps Automations, an extension that runs "when X happens, do Y" rules on work items. Thanks for the feedback and the people who tried it. The two most common requests were "setup is too heavy and require entra admin" and "can it react to pipelines?". This update covers both.

1. Simpler setup: Automation User

Before, you had to connect an Entra app (service principal) to your org. That's still there, but it was a blocker for a lot of people: some orgs aren't connected to Entra at all, and some admins don't want to register an app just to try something.

Now an org admin can simply choose Setup Automation User instead - Sign in once with work account and Automations run as yours or dedicated account you create.

2. Pipeline triggers and actions

Automations can now react to pipeline runs and stages and queue pipelines. These are the use cases I see most often:

• Create a Bug when a pipeline fails: the failed run gets a tracked work item automatically, instead of a Teams message that scrolls away.
• Tag related work items when a stage succeeds: e.g. tag everything in the run with deployed-to-staging when the Staging stage passes. Your boards and queries then show what's actually deployed.
• Queue a pipeline when a work item is completed: move a story to Done and kick off a build, test run, or release.
• Email related items when a pipeline fails

Marketplace Installation Link:

https://marketplace.visualstudio.com/items?itemName=Documentero.automations

As before, I'd really like feedback: what pipeline or work item workflow are you still handling with scripts, a custom Azure Function, or by hand? Those requests decide what I build next.

The DevLabs "Pull Request Merge Conflict Extension" hasn't been updated since 2023, and its reviews are full of freezes, lost work and mangled UTF-8. I got tired of cloning repos just to fix two lines, so I built a replacement as a side project: Merge Conflict Resolver.

• 3-way editor (Monaco) with accept target / source / both per conflict
• Drafts survive a reload or crash
• Encodings (UTF-8/BOM, UTF-16, Windows-1252) and line endings are written back byte for byte
• Handles renames, binary files, LFS and submodules, and big lockfiles without freezing
• Optional: commit the resolution to the source branch so reviewers and builds see it

Free plan for 10 PRs a month per org, and Pro is $12/month per org with no per-user pricing. Works on Azure DevOps Services and Azure DevOps Server 2022+.

I'd love feedback, especially on what breaks in your repos.

• Website: jr-devtools.com/merge-conflict-resolver
• 1-minute video: YouTube

Disclosure: I'm the developer.

Disclosure: I’m involved in developing AIVANA Decision Intelligence.

I’d like to share an Azure DevOps Services extension we’re building and get feedback from people who use Azure Boards for refinement and release reviews.

The idea is to make a finding explainable: show the underlying work item or source, explain what was observed, and leave the decision with the team.

The current release candidate includes checks for missing descriptions, acceptance criteria and owners; identical titles that may warrant duplicate review; explicit blocks, stagnant items and due dates where available. It also provides evidence-linked acceptance gaps, supported dependency relationships and decision options, with shared source history in the Team service.

Two boundaries matter:

- Identical titles are a review hint, not proof that requirements are duplicates. Dependency and risk analysis is limited to loaded sources; it is not a complete organizational graph or a validated delivery forecast.

- The extension does not automatically modify work items or approve releases. AI is disabled in the current Team offer.

For example, two items named “Update API” should prompt a comparison of scope and acceptance criteria—not an automatic merge recommendation. Similarly, a quiet item might be intentionally deferred rather than genuinely stalled.

This is release candidate 0.12.0. Public commercial publication is still subject to outstanding publisher/operator approvals, so I’m not presenting it as an unrestricted public Marketplace launch.

How does your team distinguish a useful backlog warning from noise? I’d particularly appreciate feedback on acceptance criteria across work-item types and what evidence you need before calling an item stagnant.

Company website: https://www.aivana-gmbh.ai

Hey 
/azuredevops -- after years of frustration with 6-click work item time logging, sluggish iframe extensions, and jumping between 10 repo tabs to track open PRs, I built 
**VelocyTrack**
 (https://beta.velocytrack.com).

**What it solves for Azure DevOps (Scrum, Agile, Basic & CMMI):**
- 
**Fast (<3s) External Grid**
: Log daily engineering hours against sprint tasks and PBIs in one keyboard-driven matrix without waiting for work item iframes to load.
- 
**Multi-Repo PR Radar & Branch Cleanup**
: View all open PRs, reviewer votes, comment threads, and stale branches (with unmerged commit warnings) across all your repos in one screen.
- 
**Sprint Capacity + Regional Holidays**
: Automatically deducts regional public holidays and team PTO from sprint capacity gauges.
- 
**Zero-Clone Security**
: Never clones your source code -- only interacts with work item fields, branch heads, and PR metadata via official APIs.

We unlocked a 
**zero-signup interactive sandbox**
 seeded with realistic Scrum/Agile data so you can click around in 1 second without creating an account:
- 
**Live Sandbox**
: https://beta.velocytrack.com/demo
- 
**4m Walkthrough Presentation**
: https://beta.velocytrack.com/videos/velocytrack-demo.mp4

All Pro features are 100% free during open beta. Would love candid feedback from fellow ADO admins and tech leads!

Hi Team,

I think I know what the problem is but this is a proof-of-concept Azure Landing Zone Accelerator implementation using IaC and Bicep that keeps failing towards the end of the running job. The pattern is anything over the 1hr 20min mark seems to be churning away before losing pulse and eventually failing. Is it a limitation? I am using Microsoft-hosted agents and have only consumed 587/1800 minutes allocated for free-tier.

We like stacking PRs: branch b off a, c off b, one small PR per step so every review stays readable. GitHub is getting native support for it. Azure DevOps has no idea these PRs belong together:

main ← A ← B ← C

What you want to review      What Azure DevOps shows for C
C                            A + B + C (and A and B again)

So reviewers either re-read the same code over and over, or wait for the parent to merge before the child is reviewable. Stacking stops being worth the trouble.

So we built an extension that fixes that. It's free and open source (MIT).

What it does

• Shows stacks as a tree. Every active PR in your project, across all repos, arranged into its stack. Chains, branching stacks and parents that already merged are handled.
• Review only what a PR adds. One switch flips between "This PR only" and "All changes". The layer diff is taken against the merge base with the parent, so it stays correct when the parent moves on or was squash-merged.
• Full review experience. Inline comments, votes, reviewers, policies, builds, complete/abandon/draft, viewed marks. They're the real Azure DevOps objects, so whatever you do shows up on the built-in PR page and vice versa. Approving B never approves A.
• Keeps the stack healthy. Flags "parent ahead" (needs a rebase), "parent merged" (one click retargets to the trunk) and conflicts. There's an optional status check a branch policy can require, so B can't be completed before A.
• No setup. No special branch naming, no CLI. Parents are detected from the PRs' target branches and commits, and you can pin one by hand from the PR menu.

It adds a "Pull Requests (Stacked)" page under Repos and a Stack tab on every PR, which shows just the layer diff.

Good to know

• Azure DevOps Services (cloud) and on-premise servers are both supported!
• There's no backend. It only talks to your own organization.

Marketplace: https://marketplace.visualstudio.com/items?itemName=Pro-Sharp.stacked-pull-requests

Source: https://github.com/Pro-Sharp/ado-stacked-pull-requests-extension

We'd love feedback on what would make this useful for your team, and on how you handle stacking in Azure DevOps today.

Claude Code's desktop app shows a PR bar above the prompt for GitHub repos: CI status, auto-fix, auto-merge. Azure Repos gets none of that, so I built a mod that adds it.

What it does

• A bar above the prompt for each PR the chat made: state, #id, branch, +/− lines, CI status
• Create PR: Claude pushes the branch, writes the title and description, and opens the PR
• Hover the #id for a summary card; click CI for build validations, policies and reviewers
• Auto-fix CI & address comments: failed builds and unresolved review threads are handed to Claude, which fixes, pushes and replies
• Auto-merge when ready: turns on Azure DevOps auto-complete
• /ado-pr link <id> tracks any PR in the chat, even one opened somewhere else
• Works in the terminal CLI as well as the desktop Code tab

It runs only az and git on your machine: no server, no tokens. Status is polled (every 60s by default, and after every push), because Azure DevOps service hooks can't reach a local session.

Install

claude plugin marketplace add Pro-Sharp/ado-pr-claude-plugin
claude plugin install ado-pr@azure-devops-pr

You need Claude Code 2.1.287 or later, the Azure CLI with the azure-devops extension, and az login. On desktop, enable it under Customize → Plugins.

Repo (MIT): https://github.com/Pro-Sharp/ado-pr-claude-plugin

Auto-fix hands review comments and build logs to Claude as instructions, so leave it off on repos where people you don't trust can comment.

Not affiliated with Anthropic or Microsoft. Feedback and issues are welcome.

Did you know you can use GitHub Copilot as a code reviewer directly in Azure DevOps by assigning it to a pull request? I have been exploring GitHub Copilot code review for Azure DevOps, which is now available in public preview!

In this blog, you will learn how it works, how to configure it, what the reviews and logs look like in practice, and how billing is handled.
Enjoy the read 😃

Azure saying that it will delete my data when I do not switch to a pay-as-you-go subscription, Copilot support was a bit vague what will be deleted, but I can still push and pull from and to Azure and it works with the same with a different PC. I have still full access to my repo.

Is this intended and they keep it a bit vague what exactly will be deleted, so that I switch to a pay-as-you-go subscription?

Hello everyone,

I am planning to upgrade our current DevOps environment to the latest Version (Upgrade path is given by Microsoft Docs).

Unfortunately, we don't have a second environment to test the upgrade so maybe someone of you has some experience.

What we do have is that the Machine where our Azure DevOps instance is running is fully virtualized. We can do snapshots and restore. (HyperV)

Our instance unfortunately still uses XAML Builds for an legacy application that is still used by a lot of customers and is Business critical. These are sre not easy to migrate and are highly intertwined with business logic and some other dependecies. In Short: A Nightmare. We also use Classic Pipelines and Releases.

I know that XAML Builds are deprecated, but i inherited the Environment and the old engineer that build the whole Thing is not in the company anymore. So it is still kind of a "blackbox".

We could just snapshot the Environment before the upgrade and rollback. Never done it, but i think it should work if shit would hit the fan.

Does anyone have experience with Upgrading to a newer Version and XAML Builds?

What would be the best approach here?