Retour au projet dans le portfolio

Release Bot — bot Slack de gestion des mises en production

Bot Slack en Socket Mode qui pilote les releases : quatre types de release (plateforme / application, préprod / production), workflows de statuts configurables, portes de validation avant déploiement, et synchronisation différée vers Notion au statut terminal.

Schéma générique : instances, dépôts, canaux et modules sont désignés par leur fonction. L'architecture est présentée à titre illustratif, indépendamment de toute organisation.

Étape de déploiement Porte de validation humaine Contrôle automatisé · canary · service externe Release de production Étape optionnelle Processus hôte
01 — runtime, intégrations et surfaces Slack

Architecture d'exécution

Le bot n'expose aucune URL : il ouvre lui-même une connexion sortante vers Slack (Socket Mode), garde l'état des releases en mémoire, et n'écrit dans Notion qu'une fois la release arrivée à son statut terminal.

Dev / DevOps / PO demande une release /release Slack espace de travail Socket Mode (WSS) aucune URL exposée release-bot · node 18 / pm2 moteur de workflow (@slack/bolt) Slash command /release, modales Types de release 4 workflows Machine à statuts transitions gardées Le type de release choisi fixe la suite de statuts et les boutons affichés. restitution et persistance Block Kit boutons par statut Cache en mémoire état des releases Sync différée noms Slack résolus L'état vit en mémoire ; Notion n'est écrit qu'au statut terminal. node-cron relances planifiées @notionhq/client au statut terminal Notion historique des releases surfaces slack /release — création de la release Modales chaînées (response_action: update) Boutons contextuels selon le statut courant Un fil de discussion par release Canal de release + canal de fin de release Scopes : chat:write, commands, users:read Interactivité servie par Socket Mode : pas de Request URL à exposer.
La flèche à double sens vers Slack est le seul canal réseau entrant : tout le reste sort du processus.
02 — un enchaînement par type de release

Les quatre workflows de statuts

Chaque ligne est une suite de statuts imposée par le type de release. Les cases ambre sont les seules où un humain doit trancher ; les bleues sont des contrôles automatisés ou un déploiement canary.

Plateforme Préprod Announced Deploying Control Deployed All Env Deployed Tests de charge control · clouds Deployed PO Validation GO Prod / issues / NO GO Portes avant déploiement : CD success, tests d'intégration, tests SDK — puis pose des tags sur les composants déployés et validation des feature flags. Actions post-déploiement non bloquantes : publication du SDK ou passage, lien de la pull request. Application Préprod Announced Ready to Deploy (tag image) Deploying Deployed Dev Validation PO Validation GO Prod / issues / NO GO Validation Dev obligatoire avant de déclencher la validation PO. Création directe, sans modale de confirmation. Plateforme Production Announced Images promues Started Control Deployed Canary Deployed Deployed All Env 200 Release Notified Promotion des images puis déploiement progressif : control, canary, reste du parc, contrôle 200 sur tous les environnements. Application Production Announced Started Canary Deployed Canary Validated Demo Deployed ou ignorée Deployed (clients groupés) Release Notified Les releases production de l'application reprennent les pipelines et le tag d'image validés en préprod (statuts GO Prod ou GO Prod with issues). étape de déploiement porte de validation humaine contrôle automatisé / canary étape optionnelle release de production
Les deux lignes du haut s'arrêtent sur un verdict (GO Prod / NO GO) ; les deux du bas partent de ce verdict et vont jusqu'à la notification.

Tous les schémas d'architecture