OneEnv
← All posts✅ Concept

Why Configuration Changes Need Approval Workflows

ShareLinkedInX

Teams review code but often change shared configuration with no review at all. This article is about when an approval workflow for configuration is worth its cost, what to gate, and how these workflows fail.

Why configuration deserves review

A configuration change can have the blast radius of a code change with none of the safeguards: no tests, no staged rollout, and a single edit that reaches many services. Post-incident reviews often trace back to a value that one person changed with good intentions and no knowledge of who else read it.

Common models

  • Config in Git with pull requests. Reviewers approve a diff. Strong history; reviewers rarely know all consumers, and approval is for the change, not by each consumer.
  • Code owners. A CODEOWNERS file requires owners of a path to approve. Good for ownership of files, awkward when the owners of the consumers are the ones who should agree.
  • Change advisory process. A ticket and a meeting. Visible but slow; tends to be reserved for large changes.
  • Platform-level approvals. Some secret and config platforms offer approval rules for protected values. Check what each offers, since scope and granularity vary.

What to gate

  • Values read by several services.
  • Contracts: API paths, schemas, validation rules.
  • Anything secret or whose misconfiguration is unsafe.

Leave service-private values alone; gating them is cost without benefit.

Two kinds of approval

Should this change exist? A reviewer judges the change. Can I take it now? Each consumer judges its own readiness. Most workflows only implement the first, then rely on announcements for the second. Separating them lets a consumer in the middle of a freeze decline without blocking everyone else.

How these workflows fail

  • Rubber-stamping. Reviewers approve diffs they cannot assess. Mitigate with impact information in front of the reviewer.
  • Bottlenecks. One approver on holiday stalls everyone. Define deputies.
  • Silent consumers. A pending decision nobody sees. Make unresolved decisions visible and time-boxed by convention.
  • Emergency bypasses that become normal. Allow them, log them, review them afterwards.
Where OneEnv fits (and where it does not)
OneEnv implements the two-approval split: one Owner or Admin decision on a branch, then one decision per affected service by someone holding service_admin on it (Owners and Admins can act for any service). It shows the reviewer an impact preview and score, records every step on the History page, and keeps a service on its last approved value until it approves. It does not offer comment threads, partial approval or request-changes on a branch, and it does not enforce deadlines. Rejecting and reworking on a new branch is the supported path. See Change reviews and approvals.
ShareLinkedInX