Feature Flags

Updated

October 30, 2026

Feature Flags and Deployment

After this page you can ship code to main that is not yet on for users.

A flag is a runtime switch

The commit on main contains the new code. Production does not call it until a config value is true. That is how trunk-based teams merge daily without releasing half-built ping JSON.

 main     A ← B ← C ← flag-commit ← D     all on main

 production
   DESK_PING_JSON=0   →  old string path
   DESK_PING_JSON=1   →  JSON path

 Git shipped the code at flag-commit; the env var is the release.

Toy desk-api (Python, Linux):

# src/ping.py
import os

def ping():
    if os.environ.get("DESK_PING_JSON") == "1":
        return {"status": "ok"}
    return "ok"
export DESK_PING_JSON=1
python -c 'from src.ping import ping; print(ping())'

The flag lives in the environment, a file under /etc, or a later config service. Git holds the code; the flag holds the release.

What Git still does

  • Small commits on main (or short feat/ branches)
  • Revert the commit if the code is wrong (chapter 10)
  • The flag can stay off while you fix

A flag is not a substitute for git revert when the code crashes before the flag is read.

Cleanup

Every flag is debt. When DESK_PING_JSON is on everywhere, delete the old branch in the if and the env var. A follow-up commit: chore: remove ping JSON flag.

GitOps preview

Later parts deploy from Git. A flag in the application is still an env var on the cluster. A flag in Git (a value in desk-infra) is GitOps: changing the file and merging to main is the release. Same idea, different file.