Devops

devops

devops is the Azure DevOps pipeline-first triage command for Azure-facing deployment paths.

Use it when you need to know which named pipeline or build definition already looks capable of changing Azure state or reintroducing it after cleanup.

What This Command Answers

• Which Azure DevOps definition should you inspect first?
• Which pipeline looks like a real Azure change path rather than generic DevOps inventory?
• Which definitions combine Azure service connections, auto-trigger posture, and secret-bearing support in a way that matters now?

Run It

This command needs a specific Azure DevOps organization target.

AZUREFOX_DEVOPS_ORG=<org-name> azurefox devops --output table

For saved structured output:

AZUREFOX_DEVOPS_ORG=<org-name> azurefox devops --output json

Example Table Output

project	pipeline	repo	triggers	azure access	secret support	target clues	next review
prod-platform	deploy-aks-prod	platform-api@...	continuousIntegration; auto-triggered	conn=prod-subscription; auth=ServicePrincipal; type=azurerm	groups=prod-release-...; secrets=8; kv=kv-prod-...	AKS/Kubernetes; deployment connection	Check aks, then review permissions, role-trusts, and keyvault.
platform-infra	plan-infra-prod	infra-live@...	schedule; auto-triggered	conn=infra-subscription; auth=ManagedServiceIdentity; type=azurerm	groups=platform-kv; kv=kv-platform-...	ARM/Bicep/Terraform deployment connection	Check arm-deployments, then review permissions, role-trusts, and keyvault.

When To Use It

• when the interesting path is a deployment pipeline, not just the resulting Azure resource
• when App Service, Functions, AKS, or ARM changes may be coming from CI/CD
• when you need to find the clearest named Azure change path before looking at quieter projects or definitions

What To Look For

• Azure-facing service connections
• automatic trigger posture
• variable groups with secret-bearing or Key Vault-backed inputs
• target clues that suggest App Service, Functions, AKS, ARM, or broader Azure deployment behavior

Why It Matters

Azure DevOps can be where source control, deployment logic, Azure access, and sensitive supporting inputs all meet.

The high-signal question is not "is DevOps in use?" but "which named definition already looks like a real Azure change and persistence path?" devops helps you answer that quickly by surfacing the definitions that already have service connections, auto-runs, and the sensitive inputs needed to push changes.

What Should Stand Out First

• definitions with Azure-facing service connections
• automatic trigger posture
• secret-bearing or Key Vault-backed variable groups
• the named definitions whose target clues make blast radius obvious

If You See..., Go Next To...

• If you see a top-ranked pipeline with Azure-facing service connections and auto-trigger posture, go next to Permissions and Role-Trusts because one confirms what the path can change and the other explains who can control the backing identity or app path.
• If you see key_vault_group_names or a Key Vault-backed variable group, go next to Keyvault because it shows the vault boundary supporting that Azure change path.
• If you see App Service, Functions, AKS, or ARM deployment target cues, go next to the matching service command or Arm-Deployments because those commands show the Azure surface the definition already appears built to change.

What To Do Next

• Start with the named definition, service connection, and variable-group path surfaced at the top.
• Treat Azure-facing pipelines as first-class operational control paths, not just supporting build metadata.
• Use the Azure target clues to decide whether your next step belongs in workload, identity, or deployment-history review.

Boundary

devops is a named Azure change-path command.

It should identify the definitions that most deserve review. It is not a repo browser, pipeline exporter, log-forensics workflow, or secret-retrieval command.