Projects, repositories, branch policies and environments are usually clicked into existence and never documented. They can be reconciled from YAML instead.
Infrastructure moved to code a decade ago. The delivery control plane mostly did not. Branch policies, environment approvals, repository permissions and board configuration are still typically configured by hand in a portal, undocumented and unreviewable.
The consequences show up during audits — nobody can evidence what the policy was six months ago — and during onboarding, where a new project is configured from memory and quietly differs from every other one.
The model that works
- Declare projects, repositories, policies, environments and approvals in version-controlled YAML
- A plan step producing a readable diff of what would change
- A manual approval gate before apply, because this is the control plane, not an application
- Idempotent operations that distinguish 'changed' from 'already correct' — reruns must be safe and drift must be visible
- Structured per-operation results, so a failure names the exact project and resource rather than failing the whole run opaquely
What it changes
Governance changes arrive as pull requests. They get reviewed, they leave an audit trail, and a new project inherits the same standards as every existing one because the same configuration produced it. Recreating the organisation becomes a documented operation rather than institutional memory held by one person.
No provider covers this well, so it involves working directly against the platform APIs. It is a contained piece of engineering with a disproportionate payoff.