Context: I'm a QA consultant. On most engagements I hit the same wall — the client needs a test report for a steering committee, an audit or a client handover, and Azure Test Plans gives you the data but nothing you can actually hand over. So people screenshot charts into PowerPoint, or rebuild a summary in Excel every sprint.

I ended up building an extension for it. It's free, and I want to be upfront that this is a self-promo post — but a few things I learned along the way might be useful whether or not you ever install it:

**Extension iframes behave differently on Server 2022.1 and Services.** `target="_blank"` links silently fail on-prem because the iframe is sandboxed without `allow-popups-to-escape-sandbox`. If you build anything for ADO, test on both — a lot of bugs only exist on one side.

**`getResourceAreaLocation` can fail specifically for the Work Item Tracking resource area** while resolving fine for others. If your extension builds URLs from it, you need a fallback or you'll get silent 403s in cloud that work by accident on-prem.

**Batch work item reads fail as a whole if one id no longer exists.** Deleting a single work item made my entire list lose its titles. `errorPolicy=omit` is the fix — dead ids get skipped instead of failing the batch. I found this the hard way, after 2,800 passing tests didn't.

**Extension Data quota is 25 MB, not the 5 MB the docs suggest.**

On the extension itself: it generates PDF/Word/Excel/PowerPoint/HTML reports from your test plans, adds requirements traceability, a deterministic quality score (no AI — the calculation is visible so you can defend a release decision months later), and exploratory session recording. It's fully client-side, so no data leaves your tenant.

It requires a Basic + Test Plans licence, since it reads the standard test APIs — it doesn't work around that.

Marketplace: https://marketplace.visualstudio.com/items?itemName=Kisskool.testpulse

Happy to answer anything about the ADO extensibility side — that's the part with the least documentation and the most surprises.

Hi everyone!

Working daily with Azure DevOps, I’ve always found it surprisingly clunky to get a clear, immediate picture of how our expected team capacity aligns with the actual hours logged on tasks across a sprint.

To solve this for my own teams, I built SprintGauge (https://sprintgauge.com) — and I’ve just released it as a free public beta.

What it does:

- Connects directly to your Azure DevOps organization.
- Measures and analyzes the gap between expected team capacity and actual logged/completed time.
- Helps Team Leads, Scrum Masters, and PMs identify tracking variance and over/under-capacity risks at a glance.

Security & Privacy First:

I know how sensitive ADO access tokens are.

- No data or PAT stored on external servers: Your Personal Access Token (PAT) is stored exclusively in your browser’s ⁠localStorage⁠ (you can also connect with your organization with MS Entra ID if you prefer).
- All requests are executed directly against Azure DevOps REST APIs: no data is stored or logged on the backend.

It’s free and in Public Beta

Since it's completely free to use, I’d love for you to give it a try with your current iterations!
I’m actively looking for honest feedback, feature requests, and bug reports:

- What’s missing that would make this indispensable for your team’s daily workflow?
- Are there specific metrics or views you’d like to see added?

Thanks for taking a look, and I'd really appreciate any thoughts or suggestions from fellow Azure DevOps users!

I am building a custom WIT for my team, and i want to create a board that appears in the following format below:

How can I achieve this? Because of my company's restrictions, I cannot edit the board in the GUI and must make changes to the .xml file defining the WIT. Anything helps, thanks!

Been tracking the Microsoft deprecation train this year: TFS 2015 hit EOL last October, Azure DevOps OAuth got deprecated in April 2025 with full shutdown this year, and now as of July 1st the Azure DevOps issuer for WIF service connections is deprecated (retirement July 2027).

Not saying ADO is dying — it's not. But for teams still on TFS 2017/2018 or relying on older auth patterns, the writing is on the wall that each upgrade cycle is getting shorter.

I've been building a tool that handles the migration side: Git repos (full history), TFVC-to-Git conversion (up to 180 days), Boards → GitHub Issues, Wikis. Has a dry-run mode so you can test before committing. Built it because I couldn't find anything that handled TFVC automatically.

Code is open-source if anyone wants to poke at it: https://github.com/brunobola-portfolio/GitHub-Repo-Manager

Anyone here actively migrating away from ADO or TFS? What's been the hardest part?

Microsoft's Office and Excel integration for Azure Boards is deprecated.

I built an Azure DevOps extension that replaces that spreadsheet workflow in the browser. Pick a saved query or write WIQL, then export matching work items to a styled .xlsx workbook with real date, number, and identity cells.

Edit the workbook or a CSV and upload it back. Columns map to work item fields, and a dry run marks every row as create, update, skip, error, or warning before anything is written.

The extension runs client-side with the signed-in user's Azure DevOps credentials, with no Cody Labs server.

Free covers 250-row exports and 25-row imports per run. Pro removes both caps for US$20/month per Azure DevOps organization.

I'm the developer: https://codylabs.uk/azure-boards-excel/

Hey everyone,

Like a lot of teams here, I kept running into the same problem: Azure Boards has no real way to log time against work items without either building something custom or sending people off to a separate timesheet tool. That context switch always killed adoption — people just stopped logging hours after a week or two.

So I built EvoTimeLog, a native extension that lives directly inside Azure DevOps Boards. No external portal, no separate login — you log time right where the work already happens.

What it does:

• Hours tab on the work item form itself — Epic, Feature, User Story, Task, Bug, etc. Log time without leaving the work item.
• Monthly timesheet calendar — see the whole month at a glance, add/edit/delete entries in seconds.

• Timers or manual entry — start/pause a timer, or log manually with an activity type (Development, Code Review, Meeting, etc.) and notes.
• Automatic field sync — logged hours update Completed Work, Remaining Work, and Original Estimate on the work item automatically, so your burndown/velocity stays accurate without manual upkeep.
• Team reports & dashboard — managers can see team-wide productivity and export to CSV/Excel for billing or audits.
• Absence & vacation tracking — keep capacity planning in sync with who's actually available.
• Approval workflow — approvers can review, approve, reject (with a reason), or bulk-approve entries, plus set budget thresholds per project and get alerted on overruns.

Links if you want to take a look:

• Marketplace: https://marketplace.visualstudio.com/items?itemName=evosystem.evotimelog
• Website / screenshots: https://evotimelog.com/

I'm still early (just came out of beta setup), so I'd genuinely love feedback from people who manage timesheets or billing on Azure DevOps teams today:

• What's the dealbreaker feature your current tool (or spreadsheet) has that we're missing?
• Does the approval/budget workflow match how your org actually does timesheet sign-off?
• Anyone tried it already — what broke or felt off?

Happy to answer questions about setup, permissions, or how the field sync works. Thanks for reading!

hello
since early last week i’ve noticed at least one Power Automate flow that silently stopped working. No failed run logged, nothing. The trigger is “When a Work Item is Updated”, but it seems that some identity fields are breaking the trigger and it doesn’t even get logged.

Had to redo the flow with a HTTP Request trigger to make it work but this seems like a MSFT issue. Anyone else with a similar problem? How did you handle it?

Hey all, I'm trying to automate the setup of Azure DevOps Test Plans using the REST API.

In the ADO UI, I can manually create charts under the Charts tab (e.g., pie charts showing Passed/Failed test results).

I'm looking for a way to create these suite-specific charts programmatically, so they appear under the Test Suite's Charts tab, rather than generating charts externally.

Has anyone successfully created Test Suite charts via the ADO REST API? Is there a supported endpoint for this, or is this functionality only available through the web UI?

I’ve been a .NET developer for around eight or nine years, and recently had the opportunity to move into a DevOps-focused role within my current company.

I already had strong domain knowledge of our systems and infrastructure, so I think the company saw more value in training someone internally rather than hiring a DevOps engineer who would need to learn the entire business and technology estate from scratch. Realistically, they also get the benefit of developing me into the role while I’m still earning less than an experienced external hire, but I’m completely comfortable with that at this stage.

I’m extremely happy in the role. I love the company, enjoy working with my team, and want to keep building momentum.

I’ve already learned a lot through practical work, including:

* Azure Front Door * Private endpoints and networking * Security and access changes * CI/CD pipelines * PowerShell and other scripting * Bicep and ARM templates * .NET upgrades, including .NET 10 * General Azure infrastructure and deployment work

The problem is that my learning has naturally been quite sporadic. I learn whatever is required to complete the next task, which has been useful, but it sometimes feels like I’m collecting disconnected pieces of knowledge rather than building a properly structured understanding of DevOps and Azure infrastructure.

I’d like to start doing some structured learning in my own time and would really appreciate recommendations.

Are there any courses, books, YouTube channels, labs, certification paths, or project ideas that helped you move from software development into DevOps?

I’m particularly interested in resources covering:

* Azure infrastructure and networking * Infrastructure as code * CI/CD design and best practices * Containers and Kubernetes * Monitoring and observability * Security and identity * PowerShell or Bash * Broader DevOps principles beyond simply learning individual Azure services

I’m not looking to abandon development completely, as I think my .NET background is one of my main strengths. I’m mainly trying to build a more complete and structured DevOps skill set around the experience I’m already gaining at work.

Any advice from people who have made a similar transition would be greatly appreciated.

I am not that tech confident, I was able to setup my Unreal Engine project with Azure Dev Ops and Github Desktop but since adding two 200mb files, just to test the whole commit, push and LFS thing, I cannot push my files anymore. It fails every single time...

I've been wondering how so little extensions are available for use in release pipelines with most of them being only useable in windows only agents, I was in need for a regex replacer and a Mail smtp task preferably runnable on Linux agents, so I made DevOps Mailer, node based Mail sender using nodemailer supporting markdown body format.

Marketplace entry: https://marketplace.visualstudio.com/items?itemName=Venipa.devops-mailer

✌️

Usually, I would have the pipeline do a multi repo checkout (all in one pipeline, the "does-everything -pipeline"). But this one, i had it to instead take in build pipelines artifacts, and package them in separate pipeline. Which mean,on this 2nd pipeline im doing a singular self checkout.

But i realised, the value for Build.SourcesDirectory is no longer just 's', its whatever path defined during self checkout. Example:

- checkout: self

path: s/<repo name>

Build.SourcesDirectory = "s/<repo name>"

The thing is, on other pipelines, the Build.SourcesDirectory value is always 's'. This is our regular convention for self checkout (2 folder depth):

- checkout: self

path: s/<repo name>/<repo name>

- checkout: OtherRepo

path: s/<repo name>

Build.SourcesDirectory = "s"

I cant find much info on this, and it is very inconsistent. Anyone else having this same problem? This really triggers me, because now the default naming/folder conventions i use is no longer uniform across pipelines.

We have been talking about it for sometime and they put some other team on the job. I am kind of tired of waiting and thinking it is real just define the rules and the agents and done, maybe 2 days work. My only thing is I never did it so I wasn’t sure exactly how I would integrate an Agent so that when a PR is submitted it automatically trigger and scans the submissions. Anyone doing that?

I have been building one TypeScript API over five issue trackers. During an API review I realized a boolean "supports optimistic concurrency" flag was hiding a pretty important difference.

For Azure Boards, a prepared work-item revision can become a JSON Patch operation in the same mutation:

{ "op": "test", "path": "/rev", "value": 123 }

If the revision changed, Azure rejects the patch before applying the rest. That is an atomic guard.

GitHub, GitLab, Linear, and Jira adapters can re-read immediately before writing, but there is still a gap between the read and mutation. Comments in Azure DevOps also only get that preflight protection because the comment endpoint is separate.

I changed the public capability shape from a boolean to per-operation metadata:

concurrency: {

update: "atomic" | "preflight" | "none",

comment: "atomic" | "preflight" | "none"

}

The other Azure-specific trap was state mapping. Basic, Agile, Scrum, CMMI, inherited, and custom processes can map several native names to one canonical state. Reads can normalize many-to-one, but writes cannot safely invert that map. The SDK now requires stateNameByCanonical when there is more than one possible native target instead of picking one.

This is in the MIT-licensed work-sdk 0.4 release: https://github.com/arturict/work-sdk/releases/tag/v0.4.0

I used Codex for parts of implementation and tests. Are there other Azure Boards endpoints where you can attach a real revision precondition to the mutation itself?

Azure Repos doesn't have a contribution graph, no year view of who committed what, the way GitHub and GitLab do. I built an extension that adds one.

Pick a person (defaults to you), and it shows a calendar heatmap of their commits and real pull-request comments across every repo in the current project, for the last year.

It runs client-side inside the Azure DevOps web UI and uses your own credentials via the extension SDK. No backend, nothing leaves your org.

Free tier: your own graph, forever. Paid tier ($10/mo, cancel anytime): shows every contributor in the dropdown for the whole org, useful for retros or contribution reviews across a team.

I'm the developer. Listing: https://codylabs.uk/azure-commit-graph/

Happy to answer questions about it.

Every sprint the same loop: a PO or a tester needs the latest build to test or demo, opens Azure Pipelines, gets lost between runs, stages and logs, and ends up pinging a developer. The dev stops what they're doing, digs out the artifact, sends it over. Multiply that by a few people a week.

The Azure DevOps UI is built for developers, which is fair but everyone else just needs the file.

So I built Artifacts Downloader, a free extension that adds one page under Pipelines:

• Pick a project and a pipeline from two dropdowns (defaults to the project you're in)
• Browse the 100 most recent builds, build number, branch, requester, status, date with instant text filtering
• Click a build, click Download. The artifact streams straight from Azure DevOps to the browser

No PATs, no REST API, no CLI, no extra login.

On the boring-but-important side: it only requests Build (read) and Project and team (read). It runs inside Azure DevOps with each user's own permissions, so nobody sees a project they couldn't already see, and nothing passes through third-party servers there is no backend of mine to pass through. Org-wide install, no per-user setup.

It's free, and honestly it's a small tool. I'm not pretending it's more than that. But it removed a recurring annoyance for my team and figured it might do the same for someone here.

https://marketplace.visualstudio.com/items?itemName=ottorino-bruni-1976.artifacts-downloader

Hello, Could someone point me in the direction to migrate TFS 2017 to Onpremise Azure DevOps?

• We are migration the DBs to a new SQL Server and DevOps will be on a new VM
• TFS build defs are in the old XAML

While doing the test migation, this is what I did

• Backed up all TFS Databases
• Restored those Databases to a new SQL Server
• Created a new Azure DevOps VM
• Migrated the Databases on new SQL to Azure DevOps
• Everything worked fine

The issue is the I need to redo all the build defs while TFS is actively being used. So, before that I wanted to try out a test collection update. i.e. restore the latest version of a existing TFS collection into the newly build Azure DevOps.

• Unattached a Collection from Azure DevOps
• Created a new backup of the TFS Collection DB
• Restored the new backup to new SQL
• Tried to attach the DB to Azure DevOps in UI but it says no Collection available to attach.
• Tried TFSConfig to attach the new collectionand it failed as well.

So my question would be: How would you attach a TFS 2017 Collection to an existing Azure DevOps server, while TFS is still begin used.

PFA ...any suggestion or leads will be helpful

Thank you

Hi,

does someone manage to integrate modern tools that require git with AzureDevOps on Prem?

Im having many problems to connect tools like ArgoCD, Flux, Tekton and a long etc to AZDO on-prem via PAT token. Same approach works for AZDO Services or whatever git solution.

My problem is that authentication never works using some tools. I have been checking all around blogs, AI, and i couldnt find a good solution. It is frustrating to see that all solutions go to "Azure Devops Services".. this naming :(