CI/CD para bots: tests automáticos, secretos, despliegues seguros, cambio de webhooks y rollbacks

Etapas del pipeline

1. Comprobar: lint, tipos y tests unitarios y de fixtures (pruebas de bots).
2. Construir: genera un único artefacto (imagen de contenedor, bundle) etiquetado con el SHA del commit.
3. Desplegar en staging: ejecútalo contra el bot de staging y haz una prueba de humo.
4. Promover a producción: el mismo artefacto con otra configuración.
5. Verificar: pruebas de humo automáticas y vigilancia breve de la tasa de errores.

Secretos

• Guarda los tokens en el almacén de secretos del CI o en un gestor de secretos, limitados al entorno que los necesita. Los secretos de producción solo deben estar disponibles para el trabajo de despliegue de producción.
• Nunca imprimas variables de entorno en los logs y activa el enmascarado de secretos.
• Rota los tokens cuando alguien se vaya o se filtre un log. Los tokens de Telegram se revocan en BotFather; los de Discord y Slack se regeneran en sus consolas de desarrollo.
• Valida la configuración antes de arrancar con un cargador que falle pronto; el validador de .env genera uno.

Bots de staging y producción

Usa cuentas de bot, tokens y chats de prueba distintos para cada entorno. Así los experimentos no llegan a usuarios reales y puedes probar el registro de comandos y los webhooks con seguridad.

El estado de la plataforma como código

Parte de la configuración vive en la plataforma, así que gestiónala en el pipeline:

• Discord: registra los comandos con una sobrescritura masiva (PUT /applications/{id}/commands) desde un JSON versionado. Usa comandos de servidor en staging; se actualizan al instante. Créalos con el constructor de comandos de Discord.
• Telegram: llama a setMyCommands con la misma lista que usas en el código (constructor de comandos) y a setWebhook con el token secreto tras el despliegue.
• Slack: guarda el manifiesto de la app en el repositorio y aplica los cambios a propósito.

Versiones sin cortes

• Bots con webhooks tras un balanceador: lanza instancias nuevas, comprueba su salud y luego mueve el tráfico. Haz los handlers idempotentes porque un reintento puede llegar a la versión vieja y a la nueva.
• Bots con polling deben tener un solo consumidor por token. Detén el proceso viejo antes de que el nuevo empiece a consultar o Telegram devolverá 409 Conflict. Un breve corte es aceptable; los updates esperan en el servidor hasta 24 horas.
• Bots con gateway (Discord) se reconectan y reanudan; en bots grandes, actualiza los shards de forma gradual.

Migraciones y rollback

• Haz cambios de base de datos compatibles hacia atrás: primero añade columnas, despliega el código y elimina las antiguas después.
• Conserva el artefacto anterior y un rollback de un solo comando. Revertir código es fácil; revertir el estado de la plataforma (comandos, webhooks) requiere también la configuración anterior, así que versiónala.

Ejemplo (GitHub Actions)

name: deploy
on: { push: { branches: [main] } }
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm ci && npm test
  deploy:
    needs: test
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy.sh
        env:
          BOT_TOKEN: ${{ secrets.BOT_TOKEN }}

Genera los archivos de contenedor y servicio con el generador de configuración de hosting.