Avisos de despliegue desde cualquier CI

Casi cualquier sistema de CI te avisa si falla un pipeline. Un despliegue es otra cosa: es el momento en que cambia producción, y quieres saberlo estés donde estés, con los fallos bien a la vista y los éxitos sin hacer ruido. La CLI honk-me lo hace en cualquier runner capaz de ejecutar un binario.

El patrón es siempre el mismo. Un despliegue fallido es un problema en el grupo deploy/<app>/<environment>. Uno correcto es una recuperación en ese mismo grupo: si antes hubo un fallo, cierra el incidente; si no, simplemente te confirma que salió bien.

Antes de empezar

• Una cuenta de Honk (por ahora solo con invitación: solicita acceso) y un proyecto para los despliegues, con una clave de ingesta.
• HONK_URL y HONK_KEY como secretos en tu CI.
• La CLI honk-me en la imagen de despliegue: go install github.com/honk-me/honk-go/cmd/honk-me@latest, o un binario de la página de releases.

Un script de despliegue

Si despliegas con un script, un trap avisa de cualquier línea que falle y la última línea confirma el éxito:

#!/usr/bin/env bash
# deploy.sh: tell Honk when a deploy fails, and when it worked
set -euo pipefail
app=shop env=production rev=$(git rev-parse --short HEAD)

trap 'honk-me problem --group-key "deploy/$app/$env" --title "Deploy of $app failed" \
  --message "$rev failed at line $LINENO" --category deployments || true' ERR

./build.sh
./migrate.sh
./switch.sh

# a recovery closes a failed deploy's episode; after a good one it simply notifies
honk-me recovery --group-key "deploy/$app/$env" --title "Deployed $app $rev" \
  --message "to $env" --category deployments --idempotency-key "deploy-$app-$rev" || true

La clave de idempotencia combina la app y la revisión: si lanzas dos veces el mismo despliegue, solo se notifica una vez.

GitLab CI

after_script se ejecuta al terminar el trabajo, haya salido bien o mal, y CI_JOB_STATUS indica cuál de las dos:

deploy:
  stage: deploy
  script:
    - ./deploy.sh production
  after_script:
    - |
      if [ "$CI_JOB_STATUS" = "success" ]; then
        honk-me recovery --group-key "deploy/$CI_PROJECT_PATH/production" \
          --title "Deployed $CI_PROJECT_NAME" --message "$CI_COMMIT_SHORT_SHA to production" \
          --category deployments --idempotency-key "deploy-$CI_PIPELINE_ID-ok" || true
      else
        honk-me problem --group-key "deploy/$CI_PROJECT_PATH/production" \
          --title "Deploy failed: $CI_PROJECT_NAME" --message "$CI_PIPELINE_URL" \
          --category deployments --idempotency-key "deploy-$CI_PIPELINE_ID-failed" || true
      fi

GitHub Actions

if: always() ejecuta el paso en cualquier caso, y job.status indica cómo ha ido el trabajo hasta ese momento:

      - name: Tell Honk about the deploy
        if: always()
        env:
          HONK_URL: ${{ secrets.HONK_URL }}
          HONK_KEY: ${{ secrets.HONK_KEY }}
          STATUS: ${{ job.status }}
        run: |
          if [ "$STATUS" = "success" ]; then
            honk-me recovery --group-key "deploy/${{ github.repository }}/production" \
              --title "Deployed ${{ github.repository }}" --message "${{ github.sha }} to production" \
              --category deployments --idempotency-key "deploy-${{ github.run_id }}-${{ github.run_attempt }}" || true
          else
            honk-me problem --group-key "deploy/${{ github.repository }}/production" \
              --title "Deploy failed: ${{ github.repository }}" \
              --message "${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" \
              --category deployments --idempotency-key "deploy-${{ github.run_id }}-${{ github.run_attempt }}" || true
          fi

La clave de idempotencia incluye el número de intento, así que Re-run cuenta como un despliegue nuevo, mientras que los reintentos de la propia CLI nunca lo duplican.

Despliegues correctos, con menos ruido

Una notificación por despliegue viene bien en un proyecto tranquilo, pero es demasiado en uno con mucha actividad. En lugar de tocar el pipeline, añade una regla al proyecto en la app web: si la categoría es deployments y el tipo de evento es recovery, elige Solo resumen en las notificaciones. Los éxitos llegarán agrupados cada 15 minutos, y un despliegue fallido seguirá avisando al instante.

Por qué recuperaciones y no eventos normales

Un simple evento «Desplegado» acabaría cada vez en un grupo distinto, y un despliegue fallido seguiría abierto en Atención hasta quedar inactivo un día después. Si notificas el éxito como recuperación del grupo del despliegue, el fallo se cierra en cuanto la corrección llega a producción, y todo el historial de una app y un entorno queda en un solo sitio.