Back to the project in the portfolio

Release Bot — a Slack bot for managing production releases

A Socket Mode Slack bot that drives releases: four release types (platform / application, preprod / production), configurable status workflows, approval gates before deployment, and a deferred sync to Notion at the terminal status.

Generic diagram: instances, repositories, channels and modules are named by function. The architecture is shown for illustration, independently of any organisation.

Deployment step Human approval gate Automated check · canary · external service Production release Optional step Host process
01 — runtime, integrations and Slack surfaces

Runtime architecture

The bot exposes no URL: it opens an outbound connection to Slack itself (Socket Mode), keeps release state in memory, and only writes to Notion once a release has reached its terminal status.

Dev / DevOps / PO requests a release /release Slack workspace Socket Mode (WSS) no exposed URL release-bot · node 18 / pm2 workflow engine (@slack/bolt) Slash command /release, modals Release types 4 workflows Status machine guarded transitions The chosen release type fixes the status sequence and the buttons shown. rendering and persistence Block Kit buttons per status In-memory cache release state Deferred sync Slack names resolved State lives in memory; Notion is only written at the terminal status. node-cron scheduled reminders @notionhq/client at terminal status Notion release history slack surfaces /release — creates the release Chained modals (response_action: update) Contextual buttons for the current status One discussion thread per release Release channel + release-completion channel Scopes: chat:write, commands, users:read Interactivity served over Socket Mode: no Request URL to expose.
The two-way arrow to Slack is the only inbound network channel: everything else leaves the process.
02 — one sequence per release type

The four status workflows

Each row is a status sequence imposed by the release type. The amber boxes are the only ones where a human has to decide; the blue ones are automated checks or a canary deployment.

Platform Preprod Announced Deploying Control Deployed All Env Deployed Load tests control · clouds Deployed PO Validation GO Prod / issues / NO GO Gates before deployment: CD success, integration tests, SDK tests — then tagging the deployed components and validating the feature flags. Non-blocking post-deployment actions: SDK publication or skip, pull request link. Application Preprod Announced Ready to Deploy (image tag) Deploying Deployed Dev Validation PO Validation GO Prod / issues / NO GO Dev validation is required before PO validation can be triggered. Created directly, with no confirmation modal. Platform Production Announced Images promoted Started Control Deployed Canary Deployed Deployed All Env 200 Release Notified Images are promoted, then a progressive rollout: control, canary, the rest of the estate, a 200 check on every environment. Application Production Announced Started Canary Deployed Canary Validated Demo Deployed or skipped Deployed (batched customers) Release Notified Application production releases reuse the pipelines and the image tag validated in preprod (GO Prod or GO Prod with issues statuses). deployment step human approval gate automated check / canary optional step production release
The top two rows stop at a verdict (GO Prod / NO GO); the bottom two start from that verdict and run through to the notification.

All architecture diagrams