Ring Promoter: puertas de control de calidad antes de la producción

Ver: puertas de control de calidad antes de la producción

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

Ring Promoter es el plano de control de promoción de Workstation para anillos pedidos int → test → acc → prod. Este artículo se centra en Control de calidad y puertas de calidad en ese proceso: dónde se ubican, cómo interactúa la promoción automática con las puertas humanas (especialmente antes de la producción), verificación de estado y versión como puertas de primera clase, comportamiento de reversión e implicaciones para los equipos de la plataforma de IA. Producto: ringpromoter.com · fuente: github.com/bwalia/ring-promoter. Blog complementario: resumen de negocios · descripción general: artículo moderno de CI/CD · página del producto: /promotor-anillo.

1. Proceso de promoción (resumen)

Las aplicaciones declaran objetivos de implementación por anillo (espacio de nombres, implementación, repositorio de imágenes, URL de estado, implementador). Los anillos en sí se comparten y se ordenan. Los operadores, CI o agentes llaman:

• semilla - conseguir una versión en int (o un timbre de entrada configurado).
• promover — mover la versión de from_ring hacia próximo solo anillo.
• revertir — restaurar la versión anterior en un anillo (también automático en caso de falla en el estado posterior a la implementación).

Simultaneidad: las operaciones para la misma aplicación se serializan (bloqueo de aviso de sesión Postgres entre réplicas). El contexto de operación está separado de la solicitud HTTP y limitado por operation_timeout, por lo que la desconexión de un cliente no puede cancelar una promoción en curso ni su reversión.

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. Dónde se encuentran las puertas de control de calidad

Las puertas están en capas. La promoción automática nunca pasa por alto la verificación de estado o versión; solo elimina la espera de un clic humano entre saltos cuando el aterrizaje anterior está en buen estado.

3. Promocionar automáticamente banderas por anillo

La promoción automática es opcional y por anillo. Cuando una versión llega correctamente a un anillo que tiene habilitada la promoción automática, Ring Promoter continúa al siguiente anillo dentro de la misma operación bloqueada. Bosquejo de política de ejemplo:

# 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

Las asignaciones de anillos a nivel de aplicación aún incluyen detalles de implementación y estado:

# 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

Consejo operativo: habilite la promoción automática solo después de que confíe en el contrato de salud de esa aplicación. Un débil siempre-200 El punto final más la promoción automática harán avanzar felizmente un binario incorrecto hacia la aceptación.

4. Verificación de estado y versión como puertas de calidad

Cada promoción comprueba el fuente El anillo está en buen estado antes de implementarlo, luego verifica el objetivo después de la implementación con reintentos configurables. Si el objetivo permanece en mal estado, Ring Promoter retrocede el objetivo a la versión anterior y registra el error en el historial.

Estado de versión verificada convierte una URL de vida simple en una puerta de calidad:

• health_version_field — Campo JSON en el cuerpo sanitario (p. ej. version o build.version).
• health_version_header - encabezado como X-App-Version.

La verificación requiere que el punto final informe el versión exacta recién implementada. Eso es importante para las pilas de IA: un antiguo sidecar de inferencia o un binario de agente aún puede responder 200 OK mientras que la nueva imagen nunca estuvo lista. La falta de coincidencia de versiones falla en la puerta y provoca la reversión.

En fijado por árbitro anillos (ref: release), es posible que la versión esperada no se conozca desde el principio: después de un despliegue saludable, el avión de control puede registro la versión que informa el punto final en lugar de compararla con una etiqueta conocida previamente.

5. La puerta humana acc → prod

Acuerdo auto_promote: false en acc significa un éxito test → acc (o auto encadenado de anillos anteriores) se detiene en la aceptación. La producción requiere una promoción explícita: clic en la interfaz de usuario, llamada API aprobada o automatización respaldada por ticket de cambio que aún llama a la promoción deliberadamente.

• Úselo para ventanas de cambio, aprobación de cumplimiento, demostración de las partes interesadas sobre la puesta en escena o "trenes de lanzamiento" de múltiples aplicaciones.
• Emparejar con estado de versión verificada para que el ser humano apruebe el bien construir, no una vaina sana y rancia.
• Documente quién es el propietario de la puerta (SRE de guardia, propietario del producto, gerente de lanzamiento) para que el salto no se convierta en una cola accidental.

6. Revertir como parte de la historia de la puerta

• Fallo de versión/estado posterior a la implementación → reversión automática del objetivo anillo.
• Reversión manual API/UI para recuperación impulsada por el operador.
• El historial registra el éxito y el fracaso de la inicialización, promoción y reversión para la auditoría.
• El estado almacenado se actualiza tan pronto como se realiza una implementación, por lo que la verdad del clúster no se pierde si falla una verificación de estado posterior.

Las puertas sin retroceso son un teatro. Ring Promoter trata las puertas fallidas como procesables: revertir el salto incorrecto, mantener el registro de auditoría y dejar intactos los anillos anteriores.

7. Bocetos de API (CI/agentes)

# 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

Construcciones y pruebas de CI; Ring Promoter mueve lo que produjo CI. Una promoción que no sea 2xx significa que la puerta falló. curl --fail es suficiente para la integración del oleoducto. Los agentes y los robots de liberación deben tratar acc → prod como una acción privilegiada con un paso de aprobación explícito en su propio flujo de trabajo.

8. Implicaciones para los equipos de plataformas de IA

Los estados de IA promueven servicios de inferencia, tiempos de ejecución de agentes, puertas de enlace MCP, RAG API y servicios clásicos en diferentes relojes e implementadores (kubectl, GitHub Actions y k8sjob). Los anillos compartidos dan un idioma de promoción; Gates mantiene ese lenguaje honesto:

• Estado de versión verificada capta que "el antiguo agente sigue respondiendo".
• Promocionar automáticamente mantiene los anillos de evaluación en movimiento sin cuidar cada salto.
• Puerta humana antes de pinchar Protege los modelos y herramientas de cara al cliente de una cascada silenciosa.
• Promoción de múltiples aplicaciones todavía respeta la salud por aplicación: un servicio en mal estado no inventa un anillo omitido para otros.

Postura de Workstation: tratar el envío de IA como servicios de producción: primero la observabilidad y la disciplina de promoción (ver también Cuellos de botella LLM / OTEL), luego velocidad.

9. Pros, contras y política recomendada

Valor predeterminado recomendado: promoción_automática activada int y test; puerta humana en acc; estado verificado de la versión en cada aplicación orientada al cliente; nunca te saltes los anillos; confíe en la reversión automática cuando las puertas fallan.

10. Empezando

1. Mirar youtu.be/Vs2Em0HPvoY.
2. Visita ringpromoter.com y clonar github.com/bwalia/ring-promoter.
3. Lea el blog de negocios y Workstation página del producto.
4. Configurar por anillo auto_promote y campos de versión de salud; mantenga el control humano.
5. Habla con Workstation vía contacto sobre CI/CD para plataformas de IA.

Publicado por Workstation. Documentos anteriores: README y notas de diseño en el repositorio Ring Promoter.

Sitio del producto: https://www.ringpromoter.com/