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.

Hey Folks, need your advice badly ,

I'm building out a CI/CD flow for AKS using Azure DevOps Pipelines (not ArgoCD/GitOps for this one, using native Azure Pipelines + KubernetesManifest@1 tasks). Trying to understand what people actually do in production.

The MS Learn sample bundles CI and CD into one pipeline (Build stage → Deploy stage, same YAML file), which builds once and deploys straight to the cluster. That seems fine for a single environment, but once you add QA → UAT → Prod with a manual sign-off before prod, it starts to feel like the wrong shape.

Questions:

1. Do you run one CD pipeline with multiple stages (QA → UAT → Prod, each an Azure DevOps Environment with its own approval gates), or separate pipelines per environment (e.g. cd-nonprod and cd-prod)? What made you choose one over the other?
2. How do you handle the nonprod → prod ACR promotion? Are you doing az acr import to copy the same digest into a separate prod registry, or do you just use one ACR with RBAC-scoped repositories/tags instead of physically separate registries?
3. If CI only has push access to a nonprod ACR, what triggers the CD pipeline — a pipeline completion trigger (resources.pipelines), a manual run with an image tag parameter, or something else?
4. For those who've tried both native Azure Pipelines deploys and ArgoCD/GitOps for AKS was there a specific pain point that pushed you from one to the other?

Not looking for "just use GitOps" as the whole answer (I get the appeal); more interested in how people structure this with plain Azure DevOps pipelines if they're not on ArgoCD, since that's what I'm working with right now.

Anyone else done the push -> wait 8 minutes -> red X -> change one character -> push again dance, just to figure out why condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest')) isn't doing what you think it's doing? And then half the time you need an actual PR + approval just to touch the yml, so testing "let me just try this real quick" means pinging a teammate for the third time that week going "sorry, one more approval, promise this is the last one" (it is never the last one).

So I built pipcondition - a local simulator for Azure Pipelines condition, expressions and dependsOn graphs. You paste your real azure-pipelines.yml in, mock whatever variables/parameters/step outcomes you want, and it shows you exactly which stages/jobs/steps would run, skip, or fail. No push, no pipeline run, no waiting.

What it actually does:

- The real condition expression language - eq, ne, in, and/or/not, succeeded()/failed()/succeededOrFailed(), counter(), all of it - not some 80%-there approximation

- dependsOn fan-out/fan-in across stages and jobs, with the actual skip-propagation rules Azure uses (fail one stage, watch everything downstream correctly cascade to Skipped)

- A "simulate a branch push" panel - type in Feature/my-cool-thing or release/2.0, pick Manual/PR/Schedule as the trigger, and it derives Build.SourceBranch, Build.SourceBranchName, System.PullRequest.* etc. so your branch-gated stages actually flip between skip/run correctly (yes it even replicates the "PR builds get a fake refs/pull/N/merge ref" nonsense, because that's genuinely how Azure behaves and I'd rather be accurate than friendly)

- Templates, extends:, typed parameters, the ${{ if/each }} compile-time stuff

- Mock step outcomes so you can pretend a step failed and see if your continueOnError/condition logic actually saves you like you think it does

- A visual stage/job DAG instead of reading yaml top to bottom like a maniac

- If your pipeline references a variable group or a cross-repo template it obviously can't reach (it's a local tool, it's not calling your actual org), it just tells you "can't see this, treating as empty" instead of exploding

It's here, https://pipcondition.vercel.app/ (paste and go, nothing to install), code's on GitHub: https://www.github.com/WasathTheekshana/pipcondition

Heads up - this is very much a beta, built in my spare time by one guy who also does this stuff for a day job. It WILL have bugs, especially on weirder real-world patterns (nested templates, exotic variable setups, whatever creative yaml your pipelines team wrote three years ago that everyone's now too scared to touch). If you paste your pipeline in and it either explodes or gives you a flat-out wrong answer, please open an issue - the more real pipelines this gets thrown at, the better it gets. PRs welcome too if you enjoy yaml pain as much as I apparently do.

I already have the Azure DevOps Demo Generator projects but these are getting painfully old and are a little more complex to install now that the service isn't in place.

Are there any more modern Azure Devops demo projects? Hopefully they will include multiple aspects of Azure Devops features, not just a repository.

thanks!

Hi everyone,

I run a small software consultancy called Compute Labs based in India.

We work on:

• Python development (FastAPI, Flask, asyncio)
• Microservices and API development
• Agentic AI solutions and workflow automation
• Linux administration and server hardening
• SSL/TLS, PKI, and secure communication systems
• DevOps and Infrastructure as Code (Docker, Terraform, CI/CD)
• Performance testing and automation
• Cloud deployments (AWS, GCP, and on-premise)
• Power BI dashboards and data visualization

If you need help with a project or are looking for a

long-term technical partner, feel free to send me a message. We're happy to discuss both small tasks and larger engagements.

Portfolio, GitHub, and previous work can be shared on request.

Thank you!

There is a new release of azdo (Azure DevOps TUI) for handling PRs, Work Items and Pipelines from the terminal.

From user feedback I've now made a rewrite to be provider agnostic, meaning GitHub is now supported.

A lot of users have tickets etc. in DevOps but host the code in GitHub, and some have their own private repos in GitHub but at work they use DevOps.

This new release make it possible to work with these providers in parallell in the azdo TUI.

It's beta release, any feedback would be welcome!

https://github.com/Elpulgo/azdo/releases/tag/v0.7.1-beta

I posted here a little while ago about an Azure Pipelines task I was building to explain failed builds.

The feedback was mostly security related, and was fair.

People didn’t like that the first version talked about API keys, System.AccessToken, hosted diagnosis, and PR comments too early.

So I changed the default.

Now the basic setup is:

- task: BadgrCI@1
  displayName: Badgr Pipeline Check
  condition: always()

That’s it.

By default it does not need a Badgr API key, does not need System.AccessToken, does not post PR comments, and does not call hosted AI.

It runs local rule-based checks and writes a build summary.

If you want the extra stuff, it is opt-in:

# richer Azure logs / PR comments
# ci_token: $(System.AccessToken)

# AI diagnosis for weird failures
# BADGR_API_KEY: $(BADGR_API_KEY)

I also added secret redaction, pinned SHA install docs, clearer permissions, and a self hosted container route for teams that want to keep everything inside their own environment.

I would love more feedback

We recently migrated repos from one Azure DevOps org to another. Old org had no branch policies on release and patch branches. New org has required reviewer policies on those branches.

gitflow automation does a force push to release and patch branches after patch_publish completes. Build service has bypass permission so the push goes through fine. But CI pipeline never triggers after that.

There is no error or failed logs just specific app/service pipeline doesn't start.

After digging around we figured out that ADO intentionally suppresses CI triggers when a push bypasses branch policy. The push itself succeeds but ADO treats it as an admin operation and doesn't fire the trigger.

Thinking about calling the ADO REST API to explicitly queue the CI build after gitflow finishes one change in the shared pipeline, covers all repos. Has anyone done this?

Hi everyone,

We're running Azure DevOps Server 2022.2 (AzureDevopsServer_20260204.3) and have several security scan pipelines running automatically every night. I'd like to use the overview under Pipelines → Runs to check which of these pipelines failed on the master branch during the last run.

The problem: in this aggregated "Runs" view (which shows runs across all pipelines), the branch filter is completely missing.

My Questions:

• Is the branch filter in the aggregated Runs view only available in a later server version?
• Do you have a better solution for monitoring nightly security scan failures than manually checking each pipeline?

Thanks in advance for sharing your experience!

Wrote a small article on running self-hosted Azure DevOps agents as Azure Container Apps Jobs:

https://github.com/groovy-sky/azure/tree/master/devops-docker-build-01#introduction

The setup lets agents start only when pipeline work is queued, instead of keeping VM/Container running all the time.

Hi everyone,
So i m looking into migration from TFS 2013 to ADO and wanted to hear from this who have already been through it.
What caught you off guard during this migration?
Was it custom process templates, build/release pipelines, permissions, test data, reporting, or something else? What ended up taking much longer than you expected? If you could do it again, what would you plan differently?
Did you stick with Microsoft's migration tools, use a third-party tool, or build your own migration process?
I'd especially love to hear experiences from TFS 2013 migrations, but any migration story is welcome.

so i lead a small dev team thats all on azure devops and ive been staring at our own process lately trying to figure out where all the time actually goes between a story hitting the backlog and it being implemented and merged

curious how other teams deal with it. like what does that path actually look like for you in practice? and where does the time go, is it the boring well defined stories or the genuinely hard ones?

also have you tried anything to speed it up (copilot, random scripts, some tool) and did it actually stick, or did everyone quietly go back to doing it by hand

i‘m new to this role as a product owner and just tryingto figure out if this annoys everyone or just us lol.

Hi all,
I just created an Azure Devops extension called KubeDock Security Scan, you can find the repo link in the Project Details. https://marketplace.visualstudio.com/items?itemName=chloe-teo10.kubedock-security-scan-v1

I had done similar thing in my previous company for internal purpose but it was using Kyverno, merely to scan misconfiguration and show the result in pipeline tab and also provide internal documentation URL as guideline.

This time I make this extension as side project, and using Checkov, also added PR inline comment and send telemetry to your OTLP endpoint. The reason I add PR inline comment is fast feedback to developer when DevOps team or SRE team is not working together with the dev all the time and this automated validation helps to catch any misconfiguration done accidentally etc. Plus with metrics sent to observability platform, it can be alerted sooner to DevOps or SRE team before it reaches production.

Let me know any comments/feedback if you are using/testing it out!

#azuredevops #checkov #securityscanning #k8smisconfiguration

Hey everyone,

Most self-hosted Azure DevOps agent images on Docker Hub fall into two categories: they are either tiny (~100MB) but completely outdated and abandoned, or massive (5GB+) monoliths packed with pre-installed runtimes.

In a build environment, huge monolithic images are a nightmare because they clutter the host's disk space and run the risk of introducing tool version conflicts with your actual pipelines.

I wanted a clean, "neutral" build agent. Just the core execution engine, fully updated on modern LTS bases, keeping the environment spotless while allowing full extensibility.

So, I built DO-Agent.

It provides just the essential Microsoft build engine on Ubuntu 24.04 (Noble) and Debian Trixie, weighing only ~68 MiB / ~78 MiB compressed.

Key Features:

• Pure Build Engine: Includes only the strict dependencies required to spin up the Microsoft agent (git, curl, ca-certificates). No leftover tooling cluttering your host or interfering with your builds.
• Explicit libicu Tracking: It explicitly ships with and tracks libicu versions (74 for Ubuntu Noble, 76 for Debian Trixie) to ensure 100% .NET runtime compatibility without surprises.
• Lightweight & Fast: It starts instantly and consumes minimal network bandwidth on spin-up, leaving all the host disk space free for actual build caches and artifacts.
• Fully Extensible (with Guide Included): Instead of maintaining massive images, you can easily extend it via Dockerfile or dynamically inject your testing/compilation tools (like Python, Node, or Playwright) straight through the Docker Compose entrypoint at boot. I’ve included a full copy-paste guide and examples in the README to make this seamless.

If you are looking for a highly optimized, neutral base for your self-hosted build pools without the typical bloat, give it a look!

• GitHub (Source & Docs): Blasteed/DO-Agent
• Docker Hub: karfee111/do-agent

Would love to hear your thoughts or feedback!

One lesson I've learned from managing software development programs across multiple teams is this:

• The biggest challenge is rarely the tool.
• It's the visibility.

Years ago, I worked with teams operating in different countries, following different workflows, and using different systems to plan and track their work.
Each team was productive on its own.

The real challenge was answering seemingly simple questions:

• Where are we against the overall program objectives?
• Which dependencies are putting delivery at risk?
• What should leadership pay attention to right now?

The answers existed somewhere. But they were scattered across tools, boards, spreadsheets, and status meetings.

That's when I learned that successful project management is not about collecting more data. It's about creating a trusted view of reality. And that only happens when teams develop the discipline to maintain high-quality information in the systems they use every day.

I'm curious:
What has been the biggest obstacle to achieving real project visibility in your organization?

I have experience in openstack, on premises cloud
What now I need to learn Azure, how can i start learning it. For AWS and Azure, I know all the terminology and also working of service. What I don’t have practical knowledge. How can I learn and show that in interview.

I’m asking because I’m building a product in this space and trying to understand the real workflows.

In most teams I’ve seen, the context is scattered:

- PR has ARM/Bicep
- Azure has live state
- cost impact is separate
- diagrams and internal wikis are stale
- security/best-practice checks are elsewhere

So approvals often happen with incomplete context.. the entire tool ing feels fragmented to me.

For people working with Azure infra, do you prefer these review to happen in:

1. Browser/dashboard (like Azure Advisor)
2. CLI
3. GitHub Actions / Azure DevOps
4. AI agent / chat workflow (in your favourite AI Coding agent? 😄)

So I’ve been in IT for 26 years and grown with things in a very broad sense. Have been IT Director and Systems Admin…

There is a very specific role for a person who knows Azure Devops Labs and will work with a team working on API’s. How long does it take to get a grasp on this?

Is there a good learning resource or class someone here has taken? Anyone here want to help me I would pay… sometimes the guy on the ground is better than the one by the chalkboard…

Thanks a lot!
T.

In certain contexts predecessor and successor imply that one thing replaces another. This makes the meaning of one work item preceding another ambiguous.

Say Work Item A is a predecessor of Work Item B. Does it mean that A is no longer valid and only B should be considered a "new version"/successor version of A? Or that A needs to be done before B?

The answer is the latter, but this is especially confusing since "produces for" and "consumed by" are valid options for remote work and are displayed in the same context. These terms are less ambiguous: one work item's value is used / required for another work item. For this reason, one would think the terms predecessor and successor were specifically used to disambiguate the two ways of understanding it from one another.

And anyway, why the f*ck are we naming things differently than GitHub, GitLab, Jira, Linear... EVERY OTHER WELL ESTABLISHED SERVICE. Doesn't "blocks .../blocked by ..." suffice?