A policy is a named, versioned set of quality gates. Policies are what you attach to projects; gates are what actually run.
For the concepts — blocking versus advisory, where gates sit in a run — read Quality gates first. This page covers managing them.
Find them under Quality → Policies.
Creating a policy
A policy is a set of checks plus, for each, whether failure blocks or advises.
Most organizations need two or three policies, not one per project:
- a strict policy for production services
- a standard policy for everything normal
- occasionally a light policy for internal tools and prototypes
More than that and nobody can remember which project has which.
Attaching to projects
Each project runs one policy. Change it in the project's quality settings.
A project without an explicit policy uses your organization default. Set that default to your standard policy, not your strictest — the strictest should be opted into deliberately.
Rolling out safely
The failure mode with gates is not that they are too weak. It is that a well-intentioned blocking gate stalls every task in the organization at once.
A safe sequence:
- Add the gate as advisory.
- Let it run on real work for a week or two. Read what it flags.
- Tune it against what you learned.
- Promote to blocking on one project.
- Roll out more widely once it behaves.
Versioning and rollback
Policies are versioned. Publishing creates a new version; you can roll back to a previous one.
Rollback is the reason you can afford to be decisive about publishing. If a new gate turns out to be mistuned, reverting is a single action rather than an archaeology exercise.
Overrides
A blocking gate can be overridden by someone with authority. The override is recorded — who, when, and against what.
Watch your override rate. A gate overridden most times it fires is not enforcing anything; it is generating friction and a paper trail. Either fix the gate or drop it.