商店現已上線

我們打造用於網站、AI 智慧體和 LLM 訓練的 Workstation AI 機器——線上配置併購買。

獲取同行價格
AI 產品
AI 實驗室OpenAI 智慧體Claude 代理Grok BotWorkstation AI 原生 CRM營銷所有產品
AI 解決方案
應用型 AIAI 智慧體生成式 AIAI 自動化AI 技能提升中小企業 AI 套餐企業 AI 實驗室AI 工作站NVIDIA 硬體與軟體NVIDIA 加速計算私有 AIGPU 私有云GPU 叢集邊緣 AI行業 AI
AI 服務
平臺現代化數字工程資料基礎與 AI自主運營AI 諮詢DevOps 自動化網路安全軟體開發智慧體構建MLOps 搭建GPU 租賃GPU 私有云
關於我們
公司我們的故事合作伙伴客戶案例
AI 資料中心
AI 資料中心GPU 私有云GPU 叢集GPU 租賃
AI 洞察Jev 系列基準測試實驗室模型選擇
技術說明
文件
Linux 作業系統UbuntuRed Hat Enterprise LinuxSUSE LinuxAlpine LinuxDebian、Rocky 與 AlmaLinux
AI 雲平臺AWS 與 Amazon BedrockGoogle Cloud 與 Vertex AIMicrosoft Azure 與 AI FoundryGPU 雲與算力市場
私有 AI 資料中心面向律師事務所面向會計師事務所本地部署平臺全面安全的雲
工具Ring PromoterJobshout
新聞
部落格
聯絡我們登入

面向現代企業的 AI 工作站、AI 多智慧體軟體、GPU 基礎設施和智慧代理解決方案。

聯絡我們

AI 解決方案

應用型 AIAI 智慧體生成式 AIAI 自動化AI 技能提升中小企業 AI 套餐企業 AI 實驗室行業 AI

產品

所有產品Workstation AI native CRM 與 ERP營銷OpenAI 智慧體Ring PromoterJobshout

公司

關於我們公司AI 資料中心為什麼選擇Workstation合作伙伴客戶案例定價聯絡TenthMatrix

資源

AI 洞察技術說明文件Linux 作業系統AI 雲平臺私有 AI 資料中心部落格搜尋網站地圖
英國總部
77-79 Marlowes, Hemel Hempstead HP1 1LF路線指引 — 從 M25 外環倫敦 20 號出口駛出公司編號: 11641870週一至週五:上午 9:00 - 下午 6:00 GMT
+44 7515 356 146
比利時辦公室
Workstation SRL, Rue Vanderkindere 34, 1180 Uccle, BrusselsBE 0751.518.683週一至週五:上午 9:00 - 下午 6:00 CET
+32 492 45 67 46
印度辦公室
#159 Sector 9, Pocket 1, DDA Flats, 110077 Dwarka, New Delhi
+91 98881 98841
台灣辦公室
3F, No. 2-4, Aisi Rd., Ren'ai Dist., Keelung City 200, Taiwan基隆市仁愛區愛四路2之4號3樓週一至週五:上午 9:00 - 下午 6:00 臺灣時間(GMT+8)
+886 926 892 701+32 492 45 67 46

© 2026 Workstation AI。保留所有權利。

隱私資料刪除Cookie服務條款網站地圖

NVIDIA、NVIDIA 標誌、RTX、RTX PRO、Blackwell、CUDA、NVLink、MGX、Omniverse、Spectrum-X、Quantum、BlueField、DGX 與 HGX 為 NVIDIA Corporation 在美國及其他國家的商標及/或註冊商標。AMD、AMD Arrow 標誌、EPYC、Instinct、Ryzen 與 Threadripper 為 Advanced Micro Devices, Inc. 的商標。Dell 與 PowerEdge 為 Dell Inc. 或其子公司的商標。Intel 與 Xeon 為 Intel Corporation 或其子公司的商標。AMAX、AceleMax 與 LiquidMax 為 AMAX Engineering Corporation 的商標。所有其他產品名稱、標誌與品牌均為其各自所有者之財產。我們使用它們僅為識別我們所描述、供應或支援的產品;使用這些名稱並不表示其所有者為我們背書。

首頁 / 技術說明 / Technology
DevOpsCI/CDAIKubernetesAutomation

Ring Promoter: Modern CI/CD You Cannot Miss for AI-Powered Deployments

Technical brief: ring promotion control plane, version-verified health, kubectl / GitHub Actions / k8sjob deployers, and AI-powered deployment workflows

2026年8月15日Technology5 min read

Watch: Ring Promoter quick intro (5 min)

Ring Promoter — AI-assisted promotion to production (5-minute intro)

5-minute intro: youtu.be/SjXwaTVuYhM · Product: ringpromoter.com

Ring Promoter is Workstation’s modern CI/CD promotion control plane — the tool you cannot miss for AI-powered deployments. It moves versions of many applications through ordered deployment rings int → test → acc → prod with live health gates, optional version verification, automatic rollback, and a full audit trail. Product site: https://www.ringpromoter.com/ · source: github.com/bwalia/ring-promoter. Companion: blog · product page: /ring-promoter.

Ring Promoter cover — modern CI/CD for AI deployments

Agent digest.
  • What: Shared ring pipeline for multi-app promotion with health-gated hops and auto-rollback.
  • Who: Platform, SRE, DevOps, and AI/ML teams shipping agents, APIs, gateways, and classic services.
  • Control: Embedded web UI + JSON REST API; Postgres history per (app, ring).
  • Deployers: kubectl, GitHub Actions workflow-dispatch, or Kubernetes Job runners — per app.
  • Tagline: Every release earns production.

Watch: Ring Promoter demo

Ring Promoter — Every release earns production (YouTube demo)

Workstation demo: youtu.be/IzhvmrwEebE · Product: ringpromoter.com

1. Positioning: CI/CD for the AI shipping era

AI platforms do not ship like a single monolith. You promote inference services, agent runtimes, MCP gateways, RAG APIs, and supporting microservices on different clocks — often from different repos and different deploy mechanisms (Kubernetes vs VM CI). Classic “merge to main and hope” pipelines skip rings, fake green health, and leave no shared promotion protocol across apps.

Ring Promoter is the missing control plane: one ordered set of rings, many applications, strict promotion rules, and swappable deployers. It is small enough to run on k3s, serious enough for production history and cross-replica locks, and designed so AI workloads and classical services share the same promotion language.

2. The ring model

Rings are shared and ordered (defined once). Each managed application declares, per ring, where it lives and how to reach it — namespace, Deployment, container, image repository, and a health URL. That mapping lives in configuration, not code.

Ring Role Typical AI use
intIntegrationFirst landing for agent/API builds
testTestEval suites, canary traffic, load smoke
accAcceptanceStakeholder / staging gate
prodProductionCustomer-facing AI and APIs

3. Promotion rules (non-negotiable)

  • One ring at a time; never skip. promote {from_ring} always targets the next ring in the pipeline.
  • Source must be healthy before promotion proceeds (live health check).
  • After deploy, the service runs a health check with configurable retries.
  • If the target stays unhealthy after retries, it is automatically rolled back to the previous version.
  • Every seed / promote / rollback is written to history, success or failure.
  • Auto-promote (optional, per ring): a healthy landing can continue onward in the same locked operation — e.g. auto-promote on test so int → test carries on to acc, while acc stays human-gated before prod.

4. Version-verified health (critical for AI)

A plain URL check can be fooled: the deploy “succeeds” but an old inference sidecar or previous agent binary still answers 200 OK. If a ring sets health_version_field (JSON field in the health response, e.g. version or dotted build.version) or health_version_header (e.g. X-App-Version), every post-deploy check also requires the endpoint to report the exact version that was just deployed — otherwise the check fails and auto-rollback kicks in. The same source verifies the source ring really runs the version about to be promoted.

On a ref-pinned ring (ref: release) the expected version is not knowable up front — the pipeline decides what the ref ships — so the field is used the other way: after a healthy deploy the ring records the version the endpoint reports instead of the ref name.

5. Deployers and executors

Clean interfaces keep the promotion engine stable while backends swap:

Concern Production impls
DeployKubectlDeployer, GitHubActionsDeployer, k8sjob
ExecutionGitHub Actions executor; Kubernetes Jobs executor
HealthHTTPChecker (dev: always-healthy fakes)
PersistencePostgres (prod) / memory (dev)
  • KubectlDeployer — shells out to kubectl set image + rollout status, authenticating in-cluster via ServiceAccount.
  • GitHubActionsDeployer — for VM/CI apps that already have a pipeline: triggers workflow-dispatch, waits for conclusion, then applies the same health + rollback logic.
  • k8sjob — runs seed/promote/rollback as a Job in ring-exec; runner env (RP_APP, RP_RING, RP_VERSION, …); stdout streams to step logs; exit code decides success.

The deployer is selected per application, so one control plane can promote Kubernetes apps and VM/CI apps side by side — useful when AI training jobs stay on VMs while serving runs on Kubernetes.

6. Concurrency and reliability

  • Operations on the same application are serialized by a store lock. Postgres uses a session advisory lock, so serialization holds across replicas.
  • Seed/promote/rollback runs under a context detached from the HTTP request and bounded by operation_timeout — a client disconnect cannot abort an in-flight deploy or its automatic rollback.
  • Stored state updates as soon as a deploy lands, so it never lags the cluster even if a later health check and rollback both fail.

7. Why Workstation ships Ring Promoter for AI

Workstation builds AI workstations, private AI, agent platforms, and edge products (including Workstation WSL Proxy). Those stacks need a promotion protocol that treats “AI-powered deployments” as first-class: many apps, mixed deployers, version-honest health, and human gates where they matter. Ring Promoter is that protocol — open at ringpromoter.com and integrated into Workstation solution conversations as the modern CI/CD control plane you cannot miss.

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

8. Getting started

  1. Visit https://www.ringpromoter.com/ for product context and demos.
  2. Clone github.com/bwalia/ring-promoter and run locally or on k3s.
  3. Read the Workstation product page and the blog summary.
  4. Talk to Workstation about CI/CD for AI platforms via contact.

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

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

分享這篇文章

更多 Technology 內容

AMD Instinct vs NVIDIA for AI Infrastructure: Evaluate, Port and Run Both (2026)

AMD Instinct vs NVIDIA for AI Infrastructure: Evaluate, Port and Run Both (2026)

From Lisa Su's 2024 interview to Helios: the 2026 platforms layer by layer, Instinct product lines, memory arithmetic, the CUDA-to-ROCm software map, a porting workflow with commands, dual-vendor Kubernetes, fair benchmarking, a decision workflow and day-two operations

閱讀更多
Private AI for Financial Data: Residency, Routing and Cost on AWS Bedrock, Microsoft Azure and Your Own GPUs

Private AI for Financial Data: Residency, Routing and Cost on AWS Bedrock, Microsoft Azure and Your Own GPUs

Billing models and idle cost, per-call cost at three volumes, Bedrock in-region vs EU profiles, Converse API with prompt caching and IAM region enforcement, Azure deployment types and Claude on Foundry, UK and EU providers, a residency-aware provider registry, cost-cutting workflow, a golden-set evaluation harness and GPU break-even

閱讀更多
NVKE and NVKR Technote: Building a Managed GPU Kubernetes Service from Bare Metal, with Reproducible, Verifiable Builds

NVKE and NVKR Technote: Building a Managed GPU Kubernetes Service from Bare Metal, with Reproducible, Verifiable Builds

Architecture, components and pinned versions, the NVKR Definition-Run-Release-Verify lifecycle, the full nvkectl workflow from racked servers to a customer cluster, node attestation, day-two operations, every preview limitation with a mitigation, a comparison with other approaches and a staged evaluation plan

閱讀更多