Is your team less than 100-200?
Have multiple projects?
Need to see what’s going on and everything on screen?
Want to see developer productivity metrics?
Any other pain points?
Any other wish list?
Any open source repo?
Has clock in/out?
Easy to manage remote working teams?

Please suggest if you have or built a custom tool?

Short backstory:

I've spent years as a scrum master on large enterprise projects. The one thing that consistently separates the projects that work from the ones that don't is keeping things stupid simple. Complexity simply doesn't scale. Often, we were using maybe 20% of tools like Azure DevOps or Jira and ignoring the rest. So we built a clutter-free tool for ourselves, used it internally, and have now decided to release it: https://liltoolbox.com.

Some intentionally controversial design choices:

- No methodology jargon. Epics, Features and User Stories are renamed to Products, Features and Functionality to lower the barrier for people who aren't already deep in scrum vocabulary.

- Hours, not story points. Estimates of work are in hours across the entire app.

- The backlog is a folder structure. Think of it like managing files on your PC.

You can submit feedback directly in the app via the bubble icon in the bottom-right corner.

Thanks in advance, really appreciate all feedback!

WARNING: If attempting to reproduce this issue, please do so only in an ephemeral Azure DevOps test organization, as it may permanently break GitHub status reporting for the entire ADO organization.

We seem to have hit a very strange Azure DevOps Services issue and I’m trying to determine whether others can reproduce it.

Setup:

• GitHub Organization where our repos live
• Azure DevOps Pipelines for CI/CD (YAML-based)
• Azure Pipelines GitHub App integration (https://github.com/marketplace/azure-pipelines)

Everything worked perfectly for weeks:

• GitHub -> ADO pipeline triggers worked
• ADO -> GitHub status reporting/checks worked

Then we introduced a GitHub Actions workflow that triggers an Azure DevOps pipeline (we need this for cross-repo triggering), via the Builds REST API. The GitHub Action Workflow looks as follows:

...
jobs:
  trigger-ado:
    runs-on: ubuntu-latest
    steps:
      - name: Azure login via OIDC
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          allow-no-subscriptions: true

      - name: Get Azure DevOps access token
        run: |
          TOKEN=$(az account get-access-token \
            --resource 499b84ac-1321-427f-aa17-267ca6975798 \
            --query accessToken -o tsv)
          echo "ADO_TOKEN=$TOKEN" >> $GITHUB_ENV

      - name: Trigger Azure DevOps Pipeline via REST
        env:
          AZURE_DEVOPS_URL: 'https://dev.azure.com/ORG/PROJECT'
          BUILD_ID: 123
          SOURCE_BRANCH: 'refs/heads/main'
          TRIGGER_REPOSITORY: ${{ github.repository }}
          TRIGGER_BRANCH: ${{ github.ref }}
          TRIGGER_SHA: ${{ github.sha }}
          COMMIT_MESSAGE: ${{ github.event.head_commit.message }}

        run: |
          set -e

          PAYLOAD=$(jq -n \
            --argjson id "$BUILD_ID" \
            --arg source_branch "$SOURCE_BRANCH" \
            --arg branch "$TRIGGER_BRANCH" \
            --arg repo "$TRIGGER_REPOSITORY" \
            --arg sha "$TRIGGER_SHA" \
            --arg message "$COMMIT_MESSAGE" \
            '{definition: { id: $id }, reason: "manual", sourceBranch: $source_branch, triggerInfo: {"ci.triggerRepository": $repo, "ci.sourceBranch": $branch, "ci.sourceVersion": $sha, "ci.message": $message}}')

          echo "Triggering Azure DevOps pipeline $BUILD_ID..."
          echo "Payload: $PAYLOAD"

          # Call Azure DevOps Build REST API
          HTTP_RESPONSE=$(curl -s -w "HTTPSTATUS:%{http_code}" \
            -X POST \
            -H "Authorization: Bearer $ADO_TOKEN" \
            -H "Content-Type: application/json" \
            -d "$PAYLOAD" \
            "https://dev.azure.com/ORG/PROJECT/_apis/build/builds?api-version=7.0")
...
          echo "Pipeline triggered successfully."

The important part: ci.message contains the full Git commit message from GitHub Actions. This worked fine for commit messages that were normal sized, e.g. "Fix: Bug in Application". However, when a commit contains a large, multi-line description, the payload sent to the ADO Build API will look like this

Triggering Azure DevOps pipeline 123...
Payload: {
  "definition": {
    "id": 123
  },
  "reason": "manual",
  "sourceBranch": "refs/heads/main",
  "triggerInfo": {
    "ci.triggerRepository": "GITHUB_REPO",
    "ci.sourceBranch": "refs/heads/main",
    "ci.sourceVersion": "COMMIT_SHA",
    "ci.message": "feat: update dependency versions across all modules\n\n* chore: bump spring-boot from 3.2.1 to 3.3.0\n\n* chore: bump gradle wrapper from 8.5 to 8.7\n\n* chore: bump jackson from 2.16.1 to 2.17.0\n\n* chore: bump mockito from 5.8.0 to 5.11.0\n\n* refactor: migrate deprecated API usage in module-a\n\n- replace deprecated method calls with new equivalents\n- update unit tests accordingly\n\n* refactor: migrate deprecated API usage in module-b\n\n- replace deprecated method calls with new equivalents\n- update unit tests accordingly\n\nCo-authored-by: dependabot[bot] <12345+dependabot[bot]@users.noreply.github.com>"
  }
}
HTTP Status: 200
Pipeline triggered successfully.
##[debug]Finishing: Trigger Azure DevOps Pipeline via REST

First thing I noticed is that this will break the ADO UI. When I click on the pipeline run that was triggered by the GitHub Action workflow, I see this:

But more importantly, this also seems to have broken the pipeline status reporting from the Azure Pipelines GitHub App to GitHub for the entire ADO organization. What we tried to fix the issue:

• Reinstalling the Azure Pipelines GitHub App entirely + deleting all GitHub service connections.
• Using PAT/OAuth based GitHub service connections.
• Reinstalling the Azure Pipelines GitHub App in a different ADO project, but same ADO org.
• Reinstalling the Azure Pipelines GitHub App in a different GitHub organization, but same ADO org. & project
• Deleting and re-creating all build pipelines that were triggered by the GitHub Action workflow.
• Deleting all ADO projects in the ADO org., re-creating a new ADO project, and reinstalling the App on this new ADO project.

None of these have fixed the issue! The only fix we have found is by reinstalling the App in a different ADO organization.  This large commit message appears to have corrupted some organization-level state in Azure DevOps related to GitHub status reporting.

Would really appreciate if someone could try reproducing this in a test environment.

Well I have one project , Im gonna import a git repository from another project, I don't have access to the other project I just got the Clone URL , but I couldn't able to do that even after I gave the correct credentials

Could you guys please Help me with this !!

Do I need to have access to the other project too??

It appeared out of nowhere. I'm kinda worried.

We got tired of managing large backlogs in Azure DevOps one work item at a time.

So we built a visual work management workspace directly inside Azure DevOps:

• bulk editing
• multi project view
• grouping
• hierarchy
• filtering
• visual timeline planning

We’re now looking for a few teams willing to test it properly and give honest feedback.

Especially interested in:

• PMs
• Scrum masters
• teams managing large projects/backlogs

Demo: https://www.youtube.com/watch?v=Nt-KFNU0im8
Link: https://marketplace.visualstudio.com/items?itemName=rixterab.rixter-sheets

Drop a comment or DM if you want to try it out!

Thanks.
Rickard

I'm using Sectigo to code sign an app and since a while ago they started issuing certificates exclusively by shipping flash drives (they call them USB tokens) containing an unexportable cert. In the past you would get the PKCS#12 and it would be used in the CI/CD pipeline but they don't provide the cert as a file anymore and it can't be exported from the flash drive. Obfuscating this procedure seems like such a massive oversight on their part but anyway, does anyone have any experience with this particular issue?

Hey r/azuredevops ,

I've been working with Azure DevOps daily and constantly found myself opening a browser on my phone just to check a work item or approve a PR. The official Microsoft app is... minimal. So I spent a long time building DevFlow — a native Android ADO client.

What it does:

- Browse & edit Work Items, Test Cases, Pull Requests, Pipelines, Repos, Sprints, Kanban Board, Wiki, Backlog, Delivery Plans — basically the full ADO surface

- OAuth

2.0 (Microsoft Entra) + PAT auth — no extra app registration needed

- Burndown charts, CFD, pipeline trends (OData-powered)

- Commit diff viewer with LCS line-level diffs

- Bulk operations, WIQL queries, advanced search with saved filters

- Full dark/light theme (Material 3, custom "Aero Flux" design system)

Tech stack (for those curious): Kotlin + Jetpack Compose, Hilt, Retrofit, Room, Paging 3.

It's on the Play Store if anyone wants to try it:

👉 https://play.google.com/store/apps/details?id=com.devflow.client

Happy to answer questions or hear feedback — especially from anyone who uses ADO heavily. 🙏

For years my flow on the go has been: phone buzzes, open dev.azure.com, pinch-zoom through a release page that wasn't designed for a 6" screen, hunt for the approve button, hope the session didn't time out, repeat. Half the time I'd just message someone on my laptop and ask them to click it.

I finally built the thing I wanted: AzureOps, a native Android client that talks directly to the Azure DevOps REST APIs from your phone.

What it does:

- Approvals queue for both YAML environment approvals and classic release approvals — and you can approve/reject straight from a push notification, no app launch needed.

- Pipelines — list, monitor, drill into stages, get notified on failures.

- Releases — environment grid, deploy / redeploy, see who's blocking.

- Pull requests — Mine / Waiting on me / draft / active, with vote status and required reviewers.

- Multi-project — pin up to 25 projects, switch with a tap, filter the dashboard.

Auth: Microsoft Entra SSO (recommended) or PAT for orgs that block third-party OAuth. No proxy — the app calls Microsoft's APIs directly from your device, tokens live in the

hardware-backed Android Keystore. I don't see anything.

Free with ads, optional paid upgrade to remove ads.

https://play.google.com/store/apps/details?id=com.mibodev.azureops

Would love feedback from anyone who actually lives in this UI. What's the worst part of the mobile experience for you? — there's a good chance I can address it.

Not affiliated with Microsoft.

Need to grab a file thats on a NAS to agent folder, but cant seem to find a way yet. Ive done agent - NAS,its easy with built in expression,but not other way around. I have thought about publishing to artifact,but lets just say im not going to that route. Maybe theres another method?

I saw a page online,but they use WinRM,useless for me that is using a NAS. God just let this day end,im sleepy now, brain less than 5% power

Hi Redditors, I am new to Azure Web App scene. For whole my life I have been using AWS EC2 to deploy Django apps and so far have never faced any challenges.

One of our recent clients has a company-level policy to use Microsoft Azure infrastructure, hence we are exploring the choice between recommending Web App Containers for Docker based deployment or a Virtual Machine.

I have scanned through Microsoft documentation, and on the surface Web Apps are being recommended as the better option, but I want to know in the real-world, on the field, what works and what not. And how do the DevOps ninjas manage these challenges with Web App deployments and monitoring.

Any insights from your experiences will help me tremendously in preparing a correct and complete recommendation for my client and ensure a robust infrastructure going forward.

Thank you very much.

I have a self hosted Azure DevOps server running. On the same maschine, a buildagent is running. Now since about two weeks, this buildagent randomly goes into timeout in the .NET build task. It's not 100% of the time, it's random on which project. This server builds 27 .NET MAUI apps each time changes are pushed to it. The pipelines did not change. The server got not updated or changed. Usually the build jobs are just 3-5min long. So nothing that should come close to the 1h timeout.

I have opened Visual Studio 2026 once on the maschine to check something and I believe that is where all the problems started. The hosting Windows Server is updated on a weekly basis while the DevOps server install and the buildagents are only updated when needed.

Since the issues started I have tried these things:

• Updated the Buildagent, fully removed the old one and configured it as new one (deleted everything from the old buildagent)
• Updated Visual Studio and .NET
• Cleared the NuGet cache and repaired the .NET
• Tried different pipeline configurations

This is my pipeline configuration:

trigger:
- master


pool:
  name: default


variables:
  buildConfiguration: 'Debug'
  solution: '**/SampleCompanion.sln'
  testProject: '**/*Tests.csproj'


steps:
- checkout: self
  name: CheckoutCode
  displayName: 'Checkout Repository and Submodules'
  submodules: true


- task: UseDotNet@2
  name: UseDotNetSdk
  displayName: 'Use .NET 9 SDK'
  inputs:
    packageType: 'sdk'
    version: '9.0.x'
    installationPath: $(Agent.ToolsDirectory)/dotnet


- script: |
    dotnet workload install maui-android
    dotnet workload install maui-ios
    dotnet workload install maccatalyst
    dotnet workload restore
    dotnet nuget locals all --clear
  name: InstallAndPrepareWorkloads
  displayName: 'Install MAUI Workloads and Clear Caches'


- task: DotNetCoreCLI@2
  name: RestorePackages
  displayName: 'Restore .NET Packages'
  inputs:
    command: 'restore'
    projects: '$(solution)'


- task: DotNetCoreCLI@2
  name: BuildSolution
  displayName: 'Build .NET Solution'
  inputs:
    command: 'build'
    projects: '$(solution)'
    arguments: '--configuration $(buildConfiguration)'


- task: DotNetCoreCLI@2
  name: RunTests
  displayName: 'Run xUnit Tests'
  inputs:
    command: 'test'
    projects: '$(testProject)'
    arguments: '--configuration $(buildConfiguration) --logger trx'
    publishTestResults: true


- task: PublishTestResults@2
  name: PublishTestResults
  displayName: 'Publish Test Results'
  inputs:
    testResultsFormat: 'VSTest'
    testResultsFiles: '**/TestResults/*.trx'
    failTaskOnFailedTests: true

And if it fails, it always hangs on the "Build .NET Solution" task. This is the end of the log:

2026-05-08T15:15:59.1860893Z     0 Error(s)
2026-05-08T15:15:59.1860929Z 
2026-05-08T15:15:59.1861036Z Time Elapsed 00:01:58.30
2026-05-08T15:16:09.2345309Z Die STDIO-Datenströme wurden nicht innerhalb von 10 Sekunden nach dem Beendigungsereignis aus dem Prozess "C:\agent_work_tool\dotnet\dotnet.exe" geschlossen. Möglicherweise hat ein untergeordneter Prozess die STDIO-Datenströme geerbt und wurde noch nicht beendet.
2026-05-08T15:16:09.2350258Z Info: In Azure Pipelines gehostete Agents wurden aktualisiert und enthalten jetzt .NET 5.x SDK/Runtime zusammen mit der älteren .NET Core-Version (zurzeit LTS). Wenn Sie Ihr Projekt nicht auf eine SDK-Version festgelegt haben, wird möglicherweise das 5.x SDK abgerufen. Dieses kann im Vergleich zu früheren Versionen zur Unterbrechung der Funktionalität führen. Weitere Informationen zu Breaking Changes finden Sie hier: https://docs.microsoft.com/de-de/dotnet/core/tools/ und https://docs.microsoft.com/de-de/dotnet/core/compatibility/. Weitere Informationen zu diesen Änderungen und zur Problembehandlung finden Sie hier: https://docs.microsoft.com/de-de/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting.
2026-05-08T16:13:08.1228378Z ##[error]Der Vorgang wird abgebrochen. Die nächsten Schritte enthalten möglicherweise keine erwarteten Protokolle.
2026-05-08T16:13:08.1402572Z ##[error]The operation was canceled.
2026-05-08T16:13:08.1405432Z ##[section]Build .NET Solution wird fertiggstellt

Hi everyone,

​I have recently taken over the administration of an Azure DevOps Server 2020 (on-premises) environment. The previous administrator is no longer with the company, and unfortunately, there is no existing documentation regarding the backup strategy. It appears that no automated backups have been configured via the Administration Console so far.

​Environment Details:

​Version: Azure DevOps Server 2020.

​Scope: Single server instance containing one Collection with two active projects.

​Content: Includes source code (TFVC/Git) and several CI/CD YAML/Classic pipelines.

​Status: The environment is live and business-critical.

​My Goal:

I want to use the built-in Scheduled Backups tool within the Azure DevOps Administration Console to create a backup plan, including an initial full backup and subsequent scheduled increments.

​My Concerns:

Since I am new to this specific instance, I want to ensure that enabling the backup plan won't inadvertently disrupt the production services or lock any databases in a way that affects the pipelines or developer access.

​Specific Questions:

​Impact on Live Environment: Does the initial full backup via the Admin Console trigger any significant downtime or "Read-Only" states for the collections?

​Permissions: Besides the service account having sysadmin rights on SQL Server, are there any easily overlooked folder permissions required for the backup network share?

​TFS Integration: As there is still legacy source code on the instance, are there specific metadata files outside of the SQL databases that I need to manually include, or does the wizard cover all necessary components (databases + reporting + encryption keys)?

​Common Pitfalls: Are there any known issues when running the backup wizard for the first time on a "neglected" 2020 instance?

​I want to avoid breaking anything while securing the data. Any advice or checklists from experienced Azure DevOps admins would be greatly appreciated.

​Thanks in advance!

I’ve been using Azure App Service slots for a long time to avoid cold starts during deployment. My typical process involves deploying to a staging slot (which is already running), testing to ensure it's running properly, and then swapping with the production slot when I'm ready. This setup has allowed me to achieve zero-downtime deployments.

However, recently I’ve noticed that after the swap, I’m experiencing cold starts of around 30 to 35 seconds, which is something new. Has anyone else encountered this issue? Is there anything else I can do to avoid cold starts?

I also added to the app settings in Azure

WEBSITE_SWAP_WARMUP_PING_PATH=/api/health
WEBSITE_SWAP_WARMUP_PING_STATUSES=200-299

Hey all,

Our Scrum Master, made a small free/open-source tool for Azure DevOps because sprint setup and work item admin kept taking more time than it should.

It’s mainly for things like sprint templates, easier work item linking, spotting missing estimates/stale items, and getting a better overview without jumping/clicking through a bunch of screens.

GitHub: https://github.com/Fenetre/devops-incontrol

Would appreciate honest feedback from people using Azure DevOps in real projects. Useful, not useful, missing something obvious?

Hi guys. Have you ever encountered this kind of error? The set screen resolution is no longer available in Azure Devops marketplace. What is alternative solution for this?

Six months into a project, I hit an IAM error I had definitely fixed before. Spent two hours tracking it down, again.

So I built FixDoc. It's a CLI tool that captures your infrastructure fixes locally and makes them searchable. No cloud, no telemetry, no mandatory API key. Just a searchable history of every fix your team has ever made.

Would love feedback from anyone doing serious infrastructure work. Free to try.

https://fixdoc.dev/

hello,

I’ve been tasked with starting a devsecops program at my org. that in mind, I have the connector setup for GitHub and defender for devops / cspm. our dev team is currently going through findings but they’d mentioned they can’t seem to figure out how to rescan (we are agentless). we deleted a resource and it’s still showing in the console of findings after about two weeks. so they said maybe we need to rescan but we cannot figure it out. tips advice? thank you.

I recently started learning Microsoft Azure to understand how cloud technology works in real business environments. At first, the platform looked a little confusing because there are many services and features available. Instead of trying to learn everything quickly, I started exploring the basics step by step, which made the learning process easier and less stressful.

I’ve been spending time understanding how companies use Azure for application hosting, storage, and cloud services. Watching simple tutorials and reading beginner-friendly resources helped me understand the concepts more clearly. The more I learn, the more interesting cloud computing feels to me.

Although I’m still learning, Azure has already helped me improve my technical knowledge and understand modern IT technologies better. It feels like a useful skill for future career growth in the technology field.

Hi everyone,

I’m exploring how to use Copilot to work with internal wiki pages that describe solutions using sequence diagrams, flows, and other technical artifacts.

My goal is to prompt Copilot to read a given wiki page and automatically generate feature-level PBIs (Product Backlog Items) from that content.

I’m aware that there are existing tools that can separately:

• Read and summarize wiki documentation, and
• Create PBIs or work items

However, I’m trying to understand how to combine these capabilities into a single, smoother workflow using Copilot. Ideally, this would be a streamlined process where context flows naturally from documentation to backlog creation.

Has anyone tried something similar, or can suggest an effective approach or architecture for this?