PATTERN Cited by 1 source
Git-based config workflow¶
Treat runtime configuration — feature flags, limits, tunables, ACLs — as source code living in a Git repository. Changes flow through pull requests with mandatory reviewers, CI-side schema validation, and a CD pipeline that propagates merged values to the runtime config system. Same review, audit, and rollback primitives as application code.
Components¶
- Config repo(s). Structure configs into tenants (theme + owners
- tests + dedicated CD pipeline), or per-service directories.
- Schema validation in CI. Every PR validates config values against a typed schema before a human even reviews.
- Mandatory reviewers / CODEOWNERS. Config ownership enforced at PR time.
- CD pipeline. On merge, the config platform picks up the change and initiates rollout (often staged-rollout).
- Audit history. Git log is the audit history.
Why it works¶
- Reuses existing tooling. GitHub / GitLab already provides reviews, approvals, and change history; building a bespoke config UI re-invents all of this badly.
- Consistent developer experience. Changing a config feels like changing code: familiar PR flow, same editor tooling.
- Observability integration. Config commits are first-class events — easy to correlate with deploys and incidents.
When to break the pattern¶
Git-flow latency (minutes of CI + review) is unacceptable during incidents. Platforms that take this seriously provide an emergency-bypass (a UI or API that writes directly to the data plane, logged for after-the-fact review).
Seen in¶
- sources/2026-02-18-airbnb-sitar-dynamic-configuration — Airbnb Sitar
makes Git-based configs the default path. Uses GitHub Enterprise,
groups configs into tenants with owners and tests, and runs schema
validation + CI checks on every PR.
sitar-portalis the explicit escape hatch for emergency changes.