docs: add Azure DevOps Enterprise integration

[rajshah4]

Summary

• Add an Enterprise integration guide for Azure DevOps Services using Microsoft Entra ID.
• Document Replicated and standalone Helm configuration values for Azure DevOps authentication.
• Describe Azure Repos, Azure Boards, and custom webhook/service-hook automation patterns without claiming built-in Azure DevOps event routing.
• Add the page to the Enterprise Integrations nav and mention Azure Repos/Azure Boards on the Enterprise overview page.

Validation

• python3 -c 'import json; json.load(open("docs.json"))'
• uv run --with pytest --with pyyaml pytest -q tests/test_sync_code_blocks.py tests/test_sync_use_case_automations.py

Notes

• I kept this text-only for now. The setup flow is mostly field/config based, and screenshots can be added later if reviewers want an Admin Console visual.
• make llms-check currently produces unrelated generated drift in llms.txt / llms-full.txt; I left those generated files untouched to keep this PR scoped.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
all-hands-ai	🟢 Ready	View Preview	Jun 26, 2026, 5:47 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[all-hands-bot]

✅ Review complete.

This review was performed through OpenHands Cloud Automation. You can log in and view the conversation here.

[all-hands-bot]

🟡 Acceptable — Well-structured first-class enterprise integration guide. Two documentation gaps in the Standalone Helm path need to be fixed before this merges, as they could silently break installations.

[IMPROVEMENT OPPORTUNITIES]

• [enterprise/integrations/azure-devops.mdx, Line 116] Missing format note for organization field: The Replicated tab has a <Note> block (lines 100–104) explaining the organization field must be the name only (e.g., contoso, not https://dev.azure.com/contoso). The Standalone Helm tab has the same organization: field but no equivalent note. Users who enter the full URL here will get silent failures.
• [enterprise/integrations/azure-devops.mdx, Lines 129–131] Helm secret wiring is unexplained: The text says the openhands chart reads credentials "from the Kubernetes secret named in azureDevOps.auth.existingSecret" but never explains that the openhands-secrets chart creates that secret. A reader following the Standalone Helm path sees two separate values.yaml blocks and a hardcoded existingSecret: azure-devops-app with no explanation of how the two charts connect. This is the first integration doc to cover Standalone Helm (Bitbucket Data Center is Replicated-only), so there is no prior art in this repo to fall back on — the relationship must be stated explicitly.

[RISK ASSESSMENT]

• [Overall PR] ⚠️ Risk Assessment: 🟢 LOW
  Documentation-only change. No code paths, no API surface, no behavioral change to the running product. The nav JSON addition is alphabetically correct and the JSON remains valid. The two issues above affect enterprise operators following the Standalone Helm path; they don't break anything for existing users.

VERDICT:
❌ Needs rework: The Standalone Helm tab is missing the organization-format note and the secret-wiring explanation — both of which could cause a failed deployment for an operator following the docs step by step.

KEY INSIGHT:
The Standalone Helm section describes two interdependent charts but doesn't state that the openhands-secrets chart creates the Kubernetes secret that the openhands chart references by name.

---

This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation. View conversation

---

Improve this review? If any feedback above seems incorrect or irrelevant to this repository, you can teach the reviewer to do better:

1. Add a .agents/skills/custom-codereview-guide.md file to your branch (or edit it if one already exists) with the /codereview trigger and the context the reviewer is missing. See the customization docs for the required frontmatter format.
2. Re-request a review — the reviewer reads guidelines from the PR branch, so your changes take effect immediately.
3. When your PR is merged, the guideline file goes through normal code review by repository maintainers.

Resolve with AI? Install the iterate skill in your agent and run /iterate to automatically drive this PR through CI, review, and QA until it's merge-ready.

Was this review helpful? React with 👍 or 👎 to give feedback.

[all-hands-bot]

🟠 Important: The Replicated tab has a <Note> block (lines 100–104) explicitly stating the organization field must be the name only (contoso, not https://dev.azure.com/contoso). This tab has the same organization: field with no equivalent clarification. Operators who paste the full URL here will get a silent misconfiguration — the field looks valid but repositories won't be found.

Add a note mirroring the one in the Replicated tab:

      <Note>
        The organization value is the organization name only, for example
        `contoso` for `https://dev.azure.com/contoso`. Do not include
        `https://dev.azure.com/`.
      </Note>

[all-hands-bot]

🟠 Important: The current text says the openhands chart reads credentials "from the Kubernetes secret named in azureDevOps.auth.existingSecret" but doesn't explain where that secret comes from. Readers see two separate values.yaml blocks and a hardcoded existingSecret: azure-devops-app with no explicit statement that deploying the openhands-secrets chart is what creates that secret.

This is the first integration doc in this repo to cover Standalone Helm, so there's no prior art to fall back on. Please state the relationship explicitly, for example:

Deploying the openhands-secrets chart with these values creates the Kubernetes secret named azure-devops-app. The openhands chart reads the client ID and client secret from that secret via azureDevOps.auth.existingSecret.

If the secret name is customizable, also note that both charts must use the same name.