Overview
This CI/CD automation bot sits beside the deployment pipeline and turns build logs into something human: a short, structured summary that appears inside Microsoft Teams whenever a release completes. Instead of chasing logs or refreshing dashboards, the team gets one clear update in the channel where they already collaborate.
The goal is simple: reduce the friction between “a deployment happened” and “everyone understands what just changed.” The bot captures the app, environment, status, commit SHA, and actor, and attaches deep links to observability tools or release notes when available.
Architecture
The bot is designed as a thin integration layer around an existing CI/CD system:
- CI pipeline step: A final step in GitHub Actions (or another CI tool) collects metadata about the deployment — app name, environment, status, commit, and actor.
- Notification endpoint: A small Node.js / PowerShell service receives this payload and validates that it came from a trusted pipeline run.
- Message formatter: The service builds a rich Teams message (card layout) with clear labels, emojis for status, and deep links to logs or dashboards.
- Teams channel: The final message is posted into a shared channel where SREs, developers, and stakeholders can see deployments in real time.
Sample payload from the pipeline
In many environments, the bot can be triggered with a simple curl from the CI job. Here is a simplified example that shows how the deployment metadata is sent:
curl -X POST $CI_BOT_URL/deploy-notify \
-H "Content-Type: application/json" \
-d '{
"app": "customer-portal",
"env": "production",
"status": "success",
"commit": "\${GITHUB_SHA}",
"actor": "\${GITHUB_ACTOR}"
}'On the other side, the bot translates this JSON into a clean card: “customer-portal deployed to production”, with commit, actor, and links to logs. The same pattern works for staging, hotfix branches, and multi-service environments.
Impact
Before the bot, deployments were visible only to whoever was staring at the CI console. After the bot, releases became team events: product owners, QA, and support could all see what shipped and when, without learning a new tool.
This pattern also sets up a foundation for future upgrades — adding roll-back buttons, linking to incident tickets, or correlating deployments with alerts and performance changes.
