Notificações de Deploy Automáticas

Introdução

“Já foi para produção?” — essa pergunta é feita dezenas de vezes por dia em equipes de desenvolvimento. Desenvolvedores verificam o GitHub Actions. Gerentes mandam mensagem para o lead técnico. Stakeholders ficam sem resposta. O deploy aconteceu, o ambiente caiu, e ninguém sabe em tempo real.

Esta receita elimina esse problema. Com o OpenClaw integrado ao seu pipeline de CI/CD, toda a equipe recebe notificações automáticas e detalhadas de cada deploy: quem fez, o que mudou, se funcionou, métricas pós-deploy e — o mais importante — alertas imediatos quando algo vai mal. Tudo direto no chat, sem precisar verificar dashboards ou sistemas externos.

O resultado prático: menos “já foi?” no Slack, resposta mais rápida a falhas (média de 8 minutos para detectar e 12 para iniciar rollback com notificações automáticas vs. 25+ minutos sem elas) e stakeholders informados sem precisar de updates manuais.

Veja as integrações disponíveis para GitHub, GitLab e outros sistemas de CI/CD, e consulte o glossário para termos de DevOps como webhook, pipeline e rollback.

Como Funciona

O fluxo é desencadeado automaticamente pelo seu pipeline de CI/CD:

Trigger: GitHub Actions (ou GitLab CI, Jenkins) chama o webhook do OpenClaw quando um deploy inicia
Notificação de início: OpenClaw formata e envia alerta para o canal configurado
Monitoramento: OpenClaw aguarda o resultado do deploy
Notificação de resultado: Sucesso com métricas ou falha com logs e ações sugeridas
Monitoramento pós-deploy (opcional): 30 minutos após deploy, relatório de saúde do sistema

Configuração Passo a Passo

Passo 1: Configurar o Webhook no OpenClaw

openclaw config set deploy.webhook_secret "seu-secret-aqui"
openclaw config set deploy.notify_channel "slack:#deploys"
openclaw config set deploy.notify_user "telegram:@voce"

Passo 2: Integrar ao GitHub Actions

Adicione ao seu workflow .github/workflows/deploy.yml:

- name: Notify OpenClaw — Deploy Started
  run: |
    curl -X POST "${{ secrets.OPENCLAW_WEBHOOK }}/deploy" \
      -H "Content-Type: application/json" \
      -H "X-Webhook-Secret: ${{ secrets.OPENCLAW_SECRET }}" \
      -d '{
        "event": "deploy_started",
        "project": "${{ github.repository }}",
        "branch": "${{ github.ref_name }}",
        "actor": "${{ github.actor }}",
        "commit_sha": "${{ github.sha }}",
        "commit_message": "${{ github.event.head_commit.message }}"
      }'

# ... seus steps de deploy ...

- name: Notify OpenClaw — Deploy Result
  if: always()
  run: |
    curl -X POST "${{ secrets.OPENCLAW_WEBHOOK }}/deploy" \
      -H "Content-Type: application/json" \
      -H "X-Webhook-Secret: ${{ secrets.OPENCLAW_SECRET }}" \
      -d '{
        "event": "deploy_finished",
        "status": "${{ job.status }}",
        "project": "${{ github.repository }}",
        "version": "${{ github.sha }}",
        "duration_seconds": ${{ steps.timer.outputs.duration }}
      }'

Passo 3: Configurar GitLab CI (alternativa)

# .gitlab-ci.yml
notify_deploy:
  stage: .post
  script:
    - |
      curl -X POST "$OPENCLAW_WEBHOOK/deploy" \
        -H "Content-Type: application/json" \
        -d "{\"event\": \"deploy_finished\",
             \"status\": \"$CI_JOB_STATUS\",
             \"project\": \"$CI_PROJECT_NAME\",
             \"branch\": \"$CI_COMMIT_BRANCH\",
             \"actor\": \"$GITLAB_USER_LOGIN\"}"
  when: always

Passo 4: Configurar o Soul.md para Formatação

# soul.md
Quando receber evento de deploy:
- Formate a notificação conforme o status (iniciado, sucesso, falha)
- Inclua: projeto, branch, responsável, horário
- Para falhas: inclua link de logs e sugira ação imediata
- Para sucessos: aguarde 30 minutos e envie métricas básicas
- Ambiente staging: notifique só o canal técnico
- Ambiente production: notifique canal técnico E canal geral

Passo 5: Testar

# Envie um evento de teste
curl -X POST "http://localhost:3000/webhook/deploy" \
  -H "Content-Type: application/json" \
  -d '{"event": "deploy_finished", "status": "success", "project": "teste"}'

Personalização

Filtrar por Ambiente

# config.yaml
deploy:
  environments:
    staging:
      notify_channels: ["slack:#dev-interno"]
      notify_on: ["failure"]  # Só falhas em staging
    production:
      notify_channels: ["slack:#deploys", "slack:#geral"]
      notify_on: ["started", "success", "failure"]
    hotfix:
      notify_channels: ["slack:#deploys", "telegram:@cto"]
      notify_on: ["started", "success", "failure"]
      urgent: true  # Ping imediato mesmo fora do horário

Exemplos de Uso

Notificação de Deploy Iniciado

 DEPLOY INICIADO

 Projeto: api-principal
 Branch: main → production
 Por: @diego
 Início: 14:32

Commits inclusos (3):
• fix: corrige bug de autenticação (PR #142)
• feat: adiciona endpoint de relatórios (PR #139)
• chore: atualiza dependências de segurança

ETA estimado: ~3 minutos

Notificação de Sucesso

✅ DEPLOY CONCLUÍDO

 Projeto: api-principal
 Versão: v2.4.1 (commit a3f8c21)
⏱ Duração: 2m 45s
 URL: https://api.empresa.com

 Health Check:
• Status: 200 OK ✓
• Latência média: 45ms (era 48ms)
• Taxa de erro: 0% ✓
• Memória: 312MB / 512MB

Próximo: monitorar métricas por 30min

Notificação de Falha

❌ DEPLOY FALHOU

 Projeto: api-principal
 Branch: main
⏱ Falhou em: 1m 23s
 Etapa: Testes de integração

 Erro:
"Connection refused: unable to connect to database on staging"
(5 tentativas, todas falharam)

 Logs completos: https://github.com/org/repo/actions/runs/123

 Ações sugeridas:
1. Verificar status do banco de dados de staging
2. Executar testes localmente para reproduzir
3. Se persistir, considerar reverter último commit

 Responda "rollback" para reverter para v2.4.0

Relatório de Métricas Pós-Deploy (30 min)

 RELATÓRIO PÓS-DEPLOY — 30min

✅ Sistema estável após deploy de api-principal v2.4.1

Comparativo:
• Latência p50: 42ms → 39ms (-7%) ✓
• Latência p99: 180ms → 165ms (-8%) ✓
• Taxa de erro: 0.01% → 0.00% ✓
• Throughput: 450 req/s → 480 req/s (+7%) ✓

Nenhuma anomalia detectada. Deploy bem-sucedido!

Dicas Avançadas

Rollback automático: Configure o OpenClaw para sugerir rollback se a taxa de erros ultrapassar 5% nos primeiros 10 minutos após deploy. Um comando de confirmação no chat executa a reversão.
Deploy noturno sem ruído: Em deploys programados fora do horário comercial, configure para notificar apenas falhas e suprimir notificações de sucesso até a manhã seguinte.
Agrupe deploys simultâneos: Em arquiteturas de microservices, múltiplos serviços podem deployar ao mesmo tempo. Configure um delay de 2 minutos para consolidar todas as notificações em uma única mensagem.
Integre com o monitoramento: Conecte OpenClaw com Sentry, Datadog ou New Relic para incluir métricas reais de erro rate e latência nas notificações pós-deploy. Veja as integrações.
Notifique stakeholders não-técnicos: Configure uma versão simplificada das notificações para um canal de negócios — sem jargões técnicos, apenas “nova versão no ar” ou “sistema em manutenção”.

FAQ

Funciona com Jenkins, CircleCI ou outros CI/CD? Sim. Qualquer sistema que suporte chamadas HTTP (webhooks ou curl) funciona com o OpenClaw. Configure uma chamada POST para o endpoint do OpenClaw ao início e fim de cada job.

Como configurar rollback via chat? No soul.md, defina que ao receber a palavra “rollback”, o OpenClaw deve executar o script de rollback configurado (por exemplo, um endpoint da API de deployment) e notificar o resultado. Veja o guia de skills para criar ações customizadas.

É possível aprovar deploys pelo chat antes de executar? Sim. Configure o pipeline para aguardar um webhook de aprovação do OpenClaw. Quando você enviar “aprovar deploy #142” no WhatsApp, o pipeline recebe o sinal e prossegue. Útil para deploys em produção que exigem confirmação manual.

Como lidar com falsos positivos (health checks instáveis)? Configure um delay de 2-3 minutos antes de disparar alertas de falha em health checks. Isso evita notificações para instabilidades temporárias que se resolvem sozinhas durante warmup.

Posso receber notificações de múltiplos projetos? Sim. Configure cada projeto com seu próprio webhook_secret e defina canais de notificação por projeto no config.yaml. Um único OpenClaw pode monitorar dezenas de repositórios.

Receitas Relacionadas

Code Review Automatizado — acompanhe PRs antes do deploy
Standup Diário — mantenha a equipe alinhada sobre o que foi deployado
Backup Automático — proteja configurações antes de atualizações
Integração com GitHub — configure webhooks e notificações de PR
Guia de DevOps com IA — estratégias avançadas de automação de pipeline

Primeiros Passos

Conectar

Aprender

Ajuda

Recursos

Buscar

Comunidade

Notificações de Deploy Automáticas — Receita DevOps