OpsUnity — internal platform · Platform engineering
Managing an entire Azure DevOps organisation as code
Projects, repositories, branch policies, environments and approval gates for a five-project organisation, reconciled from version-controlled YAML through plan, approval and idempotent apply.
- 5
- Projects governed from code
- 12
- Repositories under policy
- 26
- Branch policies applied declaratively
- 6
- Approval-gated environments
The challenge
Azure DevOps governance is portal-driven by default. Branch policies, environment approvals and repository permissions get configured by hand, undocumented and unreviewable — so nobody can evidence what the policy was six months ago, and each new project is configured from memory and quietly differs from the last.
Our approach
Every governance object was declared in YAML and reconciled by a purpose-built provisioner. A plan stage produces a readable diff; a manual validation gate guards apply; apply then executes a fixed operation order across projects, repositories, boards, policies, environments and approvals. Each operation is idempotent and emits a typed status, so reruns are safe and drift is visible. No Terraform provider covers this surface well, so it works directly against the Azure DevOps REST and Graph APIs.
The distinction that makes this work is between changed and already correct. Every operation reports OK, UNCHANGED, SKIP, BLOCKED or FAIL — which is what makes a rerun safe to perform and makes configuration drift something you can see rather than something you discover during an audit.
What changed operationally
- Governance changes arrive as pull requests, reviewed and recorded like any other code change
- A new project inherits the same standards as every existing one, because the same configuration produced it
- Recreating the organisation is a documented operation rather than institutional memory
- Failures name the exact project and resource instead of failing the run opaquely
What we would do differently
Drift detection should have been scheduled from the start rather than added later. Configuration applied once is configuration that begins drifting immediately, and a periodic plan is what turns the system from a provisioning tool into a control.
Facing something similar?
Tell us where your infrastructure hurts. We'll show you the pipeline out.