Ring Promoter — QA Gates Before Production

Watch: QA gates before production

Video: youtu.be/Vs2Em0HPvoY · Product: ringpromoter.com

Ring Promoter is Workstation’s promotion control plane for ordered rings int → test → acc → prod. This article focuses on QA and quality gates in that pipeline: where they sit, how auto-promote interacts with human gates (especially before prod), health and version verification as first-class gates, rollback behaviour, and implications for AI platform teams. Product: ringpromoter.com · source: github.com/bwalia/ring-promoter. Companion blog: business brief · overview: modern CI/CD article · product page: /ring-promoter.

1. Promotion process (recap)

Applications declare per-ring deploy targets (namespace, Deployment, image repo, health URL, deployer). Rings themselves are shared and ordered. Operators, CI, or agents call:

• seed — land a version on int (or a configured entry ring).
• promote — move the version from from_ring to the next ring only.
• rollback — restore the previous version on a ring (also automatic on failed post-deploy health).

Concurrency: operations for the same app are serialized (Postgres session advisory lock across replicas). The operation context is detached from the HTTP request and bounded by operation_timeout, so a client disconnect cannot abort an in-flight promote or its rollback.

Operators / CI / Agents
    → Ring Promoter (UI + REST API)
        → seed / promote / rollback
        → Deployer (kubectl | GitHub Actions | k8sjob)
        → Health (HTTP + optional version verify)  ← quality gate
        → optional auto_promote to next ring       ← policy gate
        → Store (Postgres history + locks)
Rings: int → test → acc → prod

2. Where QA gates sit

Gates are layered. Auto-promote never bypasses health or version verification — it only removes the wait for a human click between hops when the previous landing is healthy.

3. Auto-promote flags per ring

Auto-promote is optional and per ring. When a version lands healthy on a ring that has auto-promote enabled, Ring Promoter continues to the next ring inside the same locked operation. Example policy sketch:

# Conceptual ring policy (illustrative)
rings:
  - name: int
    auto_promote: true      # healthy int → continue to test
  - name: test
    auto_promote: true      # healthy test → continue to acc
  - name: acc
    auto_promote: false     # HUMAN GATE — stop before prod
  - name: prod
    auto_promote: false     # terminal ring

App-level ring mappings still carry deploy and health details:

# Per-app ring mapping (illustrative)
apps:
  web-frontend:
    rings:
      acc:
        namespace: acc-apps
        deployment: web-frontend
        health_url: https://acc.example/healthz
        health_version_field: version
      prod:
        namespace: prod-apps
        deployment: web-frontend
        health_url: https://www.example/healthz
        health_version_field: version

Operational tip: enable auto-promote only after you trust the health contract for that app. A weak always-200 endpoint plus auto-promote will happily march a bad binary toward acceptance.

4. Health and version verification as quality gates

Every promote checks the source ring is healthy before deploy, then checks the target after deploy with configurable retries. If the target stays unhealthy, Ring Promoter rolls back the target to the previous version and records failure in history.

Version-verified health turns a plain liveness URL into a quality gate:

• health_version_field — JSON field in the health body (e.g. version or build.version).
• health_version_header — header such as X-App-Version.

The check requires the endpoint to report the exact version just deployed. That matters for AI stacks: an old inference sidecar or agent binary can still answer 200 OK while the new image never became ready. Version mismatch fails the gate and triggers rollback.

On ref-pinned rings (ref: release), the expected version may not be known up front — after a healthy deploy the control plane can record the version the endpoint reports instead of comparing to a pre-known tag.

5. The acc → prod human gate

Keeping auto_promote: false on acc means a successful test → acc (or chained auto from earlier rings) stops at acceptance. Production requires an explicit promote — UI click, approved API call, or change-ticket-backed automation that still calls promote deliberately.

• Use this for change windows, compliance sign-off, stakeholder demo on staging, or multi-app “release trains.”
• Pair with version-verified health so the human is approving the right build, not a stale healthy pod.
• Document who owns the gate (SRE on-call, product owner, release manager) so the hop does not become an accidental queue.

6. Rollback as part of the gate story

• Post-deploy health/version failure → automatic rollback of the target ring.
• Manual rollback API/UI for operator-driven recovery.
• History records seed / promote / rollback success and failure for audit.
• Stored state updates as soon as a deploy lands, so cluster truth is not lost if a later health check fails.

Gates without rollback are theatre. Ring Promoter treats failed gates as actionable: reverse the bad hop, keep the audit trail, leave earlier rings intact.

7. API sketches (CI / agents)

# Seed int, then promote (auto-promote may chain further)
curl -s -H "Authorization: Bearer $TOKEN" -X POST \
  -d '{"ring":"int","version":"1.4.2"}' \
  $BASE/api/apps/web-frontend/seed

curl -s -H "Authorization: Bearer $TOKEN" -X POST \
  -d '{"from_ring":"int"}' \
  $BASE/api/apps/web-frontend/promote
# non-2xx = failed promotion (target auto-rolled back)

# Explicit human-gated hop into prod (after QA on acc)
curl -s -H "Authorization: Bearer $TOKEN" -X POST \
  -d '{"from_ring":"acc"}' \
  $BASE/api/apps/web-frontend/promote

CI builds and tests; Ring Promoter moves what CI produced. A non-2xx promote means the gate failed — curl --fail is enough for pipeline integration. Agents and release bots should treat acc → prod as a privileged action with an explicit approval step in their own workflow.

8. Implications for AI platform teams

AI estates promote inference services, agent runtimes, MCP gateways, RAG APIs, and classic services on different clocks and deployers (kubectl vs GitHub Actions vs k8sjob). Shared rings give one promotion language; gates keep that language honest:

• Version-verified health catches “old agent still answering.”
• Auto-promote keeps eval rings moving without babysitting every hop.
• Human gate before prod protects customer-facing models and tools from silent cascade.
• Multi-app promote still respects per-app health — one unhealthy service does not invent a skipped ring for others.

Workstation’s stance: treat AI shipping like production services — observability and promotion discipline first (see also LLM bottlenecks / OTEL), then speed.

9. Pros, cons, and recommended policy

Recommended default: auto_promote on int and test; human gate on acc; version-verified health on every customer-facing app; never skip rings; rely on auto-rollback when gates fail.

10. Getting started

1. Watch youtu.be/Vs2Em0HPvoY.
2. Visit ringpromoter.com and clone github.com/bwalia/ring-promoter.
3. Read the business blog and Workstation product page.
4. Configure per-ring auto_promote and health version fields; keep prod human-gated.
5. Talk to Workstation via contact about CI/CD for AI platforms.

Published by Workstation. Upstream docs: README and design notes in the Ring Promoter repository.

Product site: https://www.ringpromoter.com/