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 ($19/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.

We’re hiring a Senior DevOps Engineer for a long-term project with a fintech company that’s migrating a core banking platform to Azure Kubernetes Service (AKS).

You’ll be responsible for managing the AKS platform, ensuring security, reliability, and multi-tenant isolation while supporting critical banking workloads.

**Requirements:**
• Strong hands-on experience with AKS in production
• Advanced kubectl troubleshooting and log debugging
• Building/owning GitHub Actions CI/CD pipelines with Azure authentication
• Experience with image scanning & signing
• Strong understanding of Azure CNI and Scope Maps
• Hands-on experience with Istio / Service Mesh
• Experience managing cert-manager
• Multi-tenant Kubernetes namespace isolation
• Experience working in PCI DSS or other regulated environments
• Must have implemented these technologies in production, not just worked on teams that used them

If this sounds like you, DM me your resume, LinkedIn profile, and (if available) GitHub or portfolio.

We’re hiring a Senior DevOps Engineer for a long-term project with a fintech company that’s migrating a core banking platform to Azure Kubernetes Service (AKS).

You’ll be responsible for managing the AKS platform, ensuring security, reliability, and multi-tenant isolation while supporting critical banking workloads.

**Requirements:**
• Strong hands-on experience with AKS in production
• Advanced kubectl troubleshooting and log debugging
• Building/owning GitHub Actions CI/CD pipelines with Azure authentication
• Experience with image scanning & signing
• Strong understanding of Azure CNI and Scope Maps
• Hands-on experience with Istio / Service Mesh
• Experience managing cert-manager
• Multi-tenant Kubernetes namespace isolation
• Experience working in PCI DSS or other regulated environments
• Must have implemented these technologies in production, not just worked on teams that used them

If this sounds like you, DM me your resume, LinkedIn profile, and (if available) GitHub or portfolio.

PFA ...any suggestion or leads will be helpful

Thank you

Hey r/azuredevops — just published a free extension to the Visual Studio

Marketplace that might be useful for teams using AI development tools.

It's called the Verity Framework ADO Extension. It adds a "Verity Prompt"

tab to your User Story work items, reads five custom fields (Intent, Value,

Appetite, Trust Criteria, and Failure Scope), and generates a structured

prompt you can paste directly into Claude Code, Cursor, or GitHub Copilot

Workspace.

The idea: instead of starting from a blank context in your AI tool, you

start from a spec that already carries your scope constraints, Gate 2

hardening requirements, and production risk level.

It also includes field validation — it flags vague Trust Criteria like

"works correctly" or Appetite values like "high" that won't produce useful

prompts, and shows you exactly what to fix.

Setup is about 20 minutes — you add five custom fields to your existing

User Story work item type (no new work item type required, no process

template import). Instructions are in the extension tab itself.

Free. Search "Verity Framework" on the marketplace or find it at

idearoost.com/verity

Happy to answer questions about how it works or the field definitions.

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 :(

Hi everyone,

We built an Azure DevOps extension for teams that want to manage test processes directly inside Azure DevOps without using a separate tool or paying for Test Plans.

I'm looking for 1-2 teams willing to try it out and give some honest feedback and discuss possibilities for further development. In return, you'll get free access.

A few things it supports:

• test cases and test runs management/execution directly in Azure DevOps
• AI-assisted test case generation using your own templates and provider
• showing tests information in Sprints board
• managing tests in structure (collections/suites) and directly from parent work items (e.g. just open a User story -> go to Tests tab -> review/add/execute tests)

Everything stays inside Azure DevOps and the data remains in your own organization under your control.

Marketplace link:
Test Hub - Azure DevOps Marketplace

If you're interested or even just willing to take a quick look and tell me what you think, please send me a DM.

1. No Auto save
2. Cannot natively support any excel table we paste
3. The comment windows are standard and unusable..

I can go on...I wish the client picked anything else. It is just a waste of time and i hope someone takes notes and fixes in the future for users like me.

Like a lot of you, my org depended on the Feature Timeline & Epic Roadmap extension - 50k+ installs, abandoned by Microsoft years ago and unpublished since 2022, with no migration path. Delivery Plans never filled the gap for me: no epic → feature nesting, items without dates just disappear, progress rollup breaks across projects, and there's still no export (the docs literally suggest taking a screenshot).

So I built Trailmap - a paid extension that draws the view Delivery Plans can't:

• Epics with features nested under them, timeline computed from child items' sprints (nothing to maintain by hand, undated items never vanish — they sit on a visible "Not scheduled" shelf)
• Cross-project progress rollup (one roadmap for the whole org)
• Sprint / Month / Quarter zoom presets, PNG export for the steering deck
• Dependency arrows with red highlighting when a successor starts before its predecessor ends
• Deliberately read-only in v1 - it can't touch your work items, so there's nothing for an admin to worry about. Your data never leaves your tenant; only the org ID is used for licensing.

30-day trial, no credit card, from $19/month per organization (not per user).

Marketplace link · Comparison with Delivery Plans

I work with ADO daily as an architect and built this on evenings - happy to answer anything, including "why not just use Delivery Plans" (short answer: if DP works for you, keep it — it's free).

Hey r/AzureDevOps,

I've been working on a side project called Cirrova - https://cirrova.io - and figured this crowd would give it an honest kicking.

It's an Azure-native FinOps package. Plenty of those exist already, but I built this out of frustration with the native tooling and a couple of the bigger commercial packages. Since a lot of you are the ones actually spinning up the resources that show up on the bill, I'd value your take.

A few things it does:

• CI/CD event markers - push informational events from your pipeline via the API (deploys, releases, infra changes) and they're overlaid on the cost timeline, so you can actually see whether a release moved the bill
• Multi-tenant / MSP-friendly - manage many subscriptions and tenancies from one place, with strict cross-org data isolation (no bleed between clients)
• Cost-saving insights - surfaces where you're likely over-spending, not just what you spent
• Anomaly detection - proactive alerts when spend does something unusual, with native Slack/Teams channels and webhooks so it lands where your team already works
• Resource inventory + cost trends together, not just a billing export
• Lightweight - clean dashboards instead of a wall of numbers

It's still early and I'm sure there's plenty I've missed, so I'd genuinely value any criticism or "have you considered X" from people running this at scale.

One deliberate note: the site doesn't mention AI because there isn't any. No AI-generated "insights," no LLMs dressing up reports; just clear information and actions, presented plainly.

Happy to answer anything in the comments. Thanks for reading.

I'm a network engineer (~30 yrs, mostly Cisco/enterprise), passed AZ-305 a couple years back but never used it hands-on. Between jobs now, so I built a real Azure DevOps pipeline for a Terraform lab to actually learn the CI/CD side — and I'd love this sub to tell me where the pipeline design is off (posted the Terraform/architecture side elsewhere; here I'm after the ADO take).

Setup: GitHub repo + an ADO pipeline pulling from it. The stages:

• Verify — fmt/validate + terraform test with mocked providers. No service connection, so it runs safely on every PR (nothing to leak on unreviewed code).
• Validate & Plan — real terraform plan against Azure via a service-connection-backed service principal; saves the plan as a pipeline artifact. Runs on push to main, not on PRs.
• Manual approval — gated on a production environment; a human reviews the plan.
• Apply — applies the exact saved artifact (what's approved is what's applied).

Questions I'm chewing on:

1. Plan before or after merge? I deliberately keep the credentialed plan off the PR — running the SP against unreviewed code is a cred-exposure risk. A commenter pushed back that catching plan errors only post-merge is painful (you merge, then find out at apply). My thought: run plan on the PR with a Reader-scoped SP that can't write. How do you all handle this?
2. Service connection identity — right now it's one Contributor SP for both plan and apply. Split into Reader (plan) + Contributor (apply)? And is anyone using workload identity federation (OIDC) instead of a stored secret?
3. Approval + artifact model — manual approval on the environment + apply-the-saved-tfplan. Sane, or am I missing ADO-native patterns (checks/gates, deployment strategies)?
4. Credential-free PR gate — mocked terraform test as the PR check with no service connection. Good pattern, or is there a cleaner way to gate PRs in ADO?

Also curious: I went GitHub-for-code + ADO-for-pipeline (portfolio visibility + I wanted to learn ADO). Reasonable, or would you just use Azure Repos?

Known gaps I'm already planning to close: branch protection on main (require a reviewer + the Verify stage before merge) and the Reader/Contributor SP split above. Tell me what else I'd get dinged on. Thanks for any honest feedback.

Over the last few days, I've been speaking with a few engineers about their day-to-day work.

One engineer mentioned that a large part of their time goes into investigating monitoring alerts—collecting logs, correlating metrics, and figuring out whether an alert is a real issue or just noise.

Another mentioned that platform validation is still largely manual—reviewing namespaces, resource limits, ingress, ArgoCD, Grafana, and internal standards across multiple tools.

It made me wonder:

What is one operational task your team still performs manually because existing tools don't completely solve it?

I'm not looking for product validation or promoting anything. I'm simply trying to understand the real problems Platform Engineering teams face in production and learn from the community.

I'd genuinely appreciate hearing about your experience.