Notifications de déploiement, quelle que soit la CI

La plupart des CI savent signaler un pipeline en échec. Un déploiement, c’est autre chose : c’est le moment où la production change, et vous voulez en être informé où que vous soyez, bruyamment en cas d’échec, discrètement en cas de succès. La CLI honk-me s’en charge sur tout runner capable d’exécuter un binaire.

Le principe ne change pas d’un outil à l’autre. Un déploiement raté est un problème dans le groupe deploy/<app>/<environment>. Un déploiement réussi est un rétablissement de ce même groupe : après un échec, il clôt l’incident ; après un succès, il vous confirme simplement que tout s’est bien passé.

Avant de commencer

• Un compte Honk (pour l’instant sur invitation : demandez un accès) et un projet dédié aux déploiements, avec une clé d’ingestion.
• HONK_URL et HONK_KEY enregistrés comme secrets dans votre CI.
• La CLI honk-me dans l’image de déploiement : go install github.com/honk-me/honk-go/cmd/honk-me@latest, ou un binaire depuis la page des releases.

Un script de déploiement

Si vous déployez avec un script, un trap signale toute commande qui échoue, et la dernière ligne signale le succès :

#!/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 clé d’idempotence associe l’app et la révision : le même déploiement lancé deux fois n’est signalé qu’une fois.

GitLab CI

after_script s’exécute après le job, qu’il ait réussi ou échoué, et CI_JOB_STATUS indique son issue :

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() exécute l’étape dans tous les cas, et job.status indique comment le job s’est déroulé jusque-là :

      - 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 clé d’idempotence inclut le numéro de tentative : un Re-run est signalé comme un nouveau déploiement, alors que les nouvelles tentatives internes de la CLI ne créent jamais de doublon.

Des déploiements réussis plus discrets

Un push par déploiement, c’est utile sur un projet calme, mais trop sur un projet très actif. Plutôt que de modifier le pipeline, ajoutez une règle au projet dans l’app web : si la catégorie est deployments et le type d’événement recovery, choisissez Récapitulatif uniquement. Les succès arrivent alors groupés toutes les 15 minutes, et un déploiement raté déclenche toujours un push immédiat.

Pourquoi des rétablissements plutôt que de simples événements

Un simple événement « Déployé » créerait chaque fois son propre groupe, et un déploiement raté resterait ouvert dans « À traiter » jusqu’à devenir inactif, un jour plus tard. Signaler le succès comme un rétablissement clôt l’échec dès que le correctif est en ligne, et réunit tout l’historique d’une app et d’un environnement au même endroit.