Ring Promoter — Portes d'assurance qualité avant la production

Regarder : portes d'assurance qualité avant la production

Vidéo: youtu.be/Vs2Em0HPvoY · Produit: ringpromoter.com

Ring Promoter est le plan de contrôle de promotion de Workstation pour les bagues commandées int → test → acc → prod. Cet article se concentre sur Contrôle qualité et contrôle de la qualité dans ce pipeline: où ils se situent, comment la promotion automatique interagit avec les portes humaines (en particulier avant la production), vérification de l'état et de la version en tant que portes de première classe, comportement de restauration et implications pour les équipes de la plateforme d'IA. Produit: ringpromoter.com · source: github.com/bwalia/ring-promoter. Blog compagnon : dossier d'affaires · aperçu: article CI/CD moderne · fiche produit : /promoteur-anneau.

1. Processus de promotion (récapitulatif)

Les applications déclarent des cibles de déploiement par anneau (espace de noms, déploiement, dépôt d'images, URL d'intégrité, déployeur). Les bagues elles-mêmes sont partagées et commandées. Les opérateurs, CI ou agents appellent :

• graine — débarquer une version sur int (ou une sonnerie d'entrée configurée).
• promouvoir — déplacer la version de from_ring au suivant bague seulement.
• restauration - restaurer la version précédente sur un anneau (également automatique en cas d'échec de l'intégrité post-déploiement).

Concurrence : les opérations pour la même application sont sérialisées (verrouillage consultatif de session Postgres sur les réplicas). Le contexte d'opération est détaché de la requête HTTP et délimité par operation_timeout, donc une déconnexion client ne peut pas abandonner une promotion en cours ou son annulation.

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. Où se situent les portes de l’assurance qualité

Les portes sont superposées. La promotion automatique ne contourne jamais la vérification de l’état ou de la version : elle supprime uniquement l’attente d’un clic humain entre les sauts lorsque l’atterrissage précédent est sain.

3. Promotion automatique des drapeaux par anneau

La promotion automatique est en option et par sonnerie. Lorsqu'une version atterrit correctement sur un anneau sur lequel la promotion automatique est activée, Ring Promoter passe à l'anneau suivant dans la même opération verrouillée. Exemple d’esquisse de politique :

# 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

Les mappages en anneau au niveau de l'application contiennent toujours des détails sur le déploiement et l'état :

# 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

Conseil opérationnel : activez la promotion automatique uniquement après avoir fait confiance au contrat de santé pour cette application. Un faible toujours-200 le point de terminaison plus la promotion automatique feront volontiers avancer un mauvais binaire vers l'acceptation.

4. Vérification de l'état de santé et des versions comme portes de qualité

Chaque promotion vérifie le source l'anneau est sain avant le déploiement, puis vérifie le cible après le déploiement avec des tentatives configurables. Si la cible reste en mauvais état, Ring Promoter recule la cible vers la version précédente et enregistre les échecs dans l'historique.

État de santé vérifié par version transforme une URL simple et vivante en un portail de qualité :

• health_version_field — Champ JSON dans l'organisme de santé (ex. version ou build.version).
• health_version_header — en-tête tel que X-App-Version.

La vérification nécessite que le point final signale le version exacte qui vient d'être déployée. C’est important pour les piles d’IA : un ancien side-car d’inférence ou un ancien binaire d’agent peut toujours répondre 200 OK alors que la nouvelle image n’était jamais prête. L'incompatibilité de version fait échouer la porte et déclenche une restauration.

Sur réf-épinglé anneaux (ref: release), la version attendue peut ne pas être connue à l'avance — après un déploiement sain, le plan de contrôle peut enregistrer la version signalée par le point de terminaison au lieu de la comparer à une balise pré-connue.

5. La porte humaine acc → prod

Garde auto_promote: false sur acc signifie un succès test → acc (ou auto enchaîné des anneaux précédents) s'arrête à l'acceptation. La production nécessite une promotion explicite : clic sur l'interface utilisateur, appel API approuvé ou automatisation basée sur un ticket de modification qui appelle toujours délibérément la promotion.

• Utilisez-le pour les fenêtres de changement, l'approbation de la conformité, la démonstration des parties prenantes sur la préparation ou les « trains de publication » multi-applications.
• Associez-le à l’état de santé vérifié par version afin que l’humain approuve le droite construire, pas une capsule saine et périmée.
• Documentez le propriétaire de la porte (SRE de garde, propriétaire du produit, responsable des versions) afin que le saut ne devienne pas une file d'attente accidentelle.

6. Rollback dans le cadre de l'histoire de la porte

• Échec de l’état de santé/de la version après le déploiement → restauration automatique du cible anneau.
• Restauration manuelle API/UI pour une récupération pilotée par l'opérateur.
• L’historique enregistre le succès et l’échec de l’amorçage/promotion/annulation pour l’audit.
• L'état stocké est mis à jour dès qu'un déploiement est effectué, de sorte que la vérité sur le cluster n'est pas perdue en cas d'échec d'un contrôle de santé ultérieur.

Les portes sans recul sont du théâtre. Ring Promoter traite les portes défaillantes comme étant exploitables : inversez le mauvais saut, conservez la piste d'audit, laissez les anneaux précédents intacts.

7. Croquis API (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

Constructions et tests CI ; Ring Promoter déplace ce que CI a produit. Une promotion non-2xx signifie que la porte a échoué — curl --fail est suffisant pour l’intégration du pipeline. Les agents et les robots de publication doivent traiter acc → prod comme une action privilégiée avec une étape d'approbation explicite dans leur propre workflow.

8. Implications pour les équipes de la plateforme AI

Les domaines d'IA font la promotion des services d'inférence, des environnements d'exécution d'agent, des passerelles MCP, des RAG API et des services classiques sur différentes horloges et déployeurs (kubectl vs GitHub Actions vs k8sjob). Les anneaux partagés donnent une langue de promotion ; les portes gardent ce langage honnête :

• État de santé vérifié par version » surprend « l'ancien agent répond toujours ».
• Promotion automatique maintient les anneaux d'évaluation en mouvement sans surveiller chaque saut.
• Porte humaine avant la production protège les modèles et les outils destinés aux clients de la cascade silencieuse.
• Promotion multi-applications respecte toujours la santé de chaque application : un service en mauvais état n'invente pas de sonnerie ignorée pour les autres.

La position de Workstation : traiter l’expédition de l’IA comme des services de production – l’observabilité et la discipline de promotion d’abord (voir aussi Goulots d'étranglement LLM / OTEL), puis vitesse.

9. Avantages, inconvénients et politique recommandée

Valeur par défaut recommandée : auto_promote activé int et test; porte humaine ouverte acc; état de santé vérifié par version sur chaque application destinée aux clients ; ne sautez jamais de bagues ; comptez sur le retour en arrière automatique lorsque les portes échouent.

10. Pour commencer

1. Montre youtu.be/Vs2Em0HPvoY.
2. Visite ringpromoter.com et cloner github.com/bwalia/ring-promoter.
3. Lire le blog d'affaires et Workstation fiche produit.
4. Configurer par sonnerie auto_promote et les champs de version santé ; gardez la prod fermée aux humains.
5. Parlez à Workstation via contact à propos du CI/CD pour les plateformes d'IA.

Publié par Workstation. Documents en amont : README et notes de conception dans le référentiel Ring Promoter.

Site produit : https://www.ringpromoter.com/