Push-Benachrichtigungen für Deploys aus jeder CI

Die meisten CI-Systeme melden eine fehlgeschlagene Pipeline. Ein Deploy ist etwas anderes: In diesem Moment ändert sich die Produktion. Das willst du mitbekommen, egal wo du bist, und zwar laut, wenn es schiefgeht, und leise, wenn es klappt. Die honk-me-CLI erledigt das in jedem Runner, der ein Binary ausführen kann.

Das Muster ist überall gleich. Ein fehlgeschlagener Deploy ist ein Problem in der Gruppe deploy/<app>/<environment>. Ein erfolgreicher Deploy ist eine Entwarnung für dieselbe Gruppe. Nach einem Fehlschlag schließt sie den Vorfall, nach einem guten Deploy sagt sie dir einfach, dass alles geklappt hat.

Voraussetzungen

• Ein Honk-Konto (vorerst nur auf Einladung: Zugang anfragen) und ein Projekt für Deploys mit Ingest-Schlüssel.
• HONK_URL und HONK_KEY als Secrets in deiner CI.
• Die honk-me-CLI im Deploy-Image: go install github.com/honk-me/honk-go/cmd/honk-me@latest, oder ein Binary von der Releases-Seite.

Ein Deploy-Skript

Wenn du per Skript deployst, meldet ein trap jede fehlschlagende Zeile, und die letzte Zeile meldet den Erfolg:

#!/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

Der Idempotency-Key besteht aus App und Revision. Läuft derselbe Deploy zweimal, wird er also nur einmal gemeldet.

GitLab CI

after_script läuft nach dem Job, ob er nun erfolgreich war oder nicht. Welches von beiden, steht in CI_JOB_STATUS:

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() führt den Schritt in jedem Fall aus, und job.status verrät, wie der Job bis dahin gelaufen ist:

      - 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

Der Idempotency-Key enthält die Versuchsnummer des Laufs. Re-run meldet also einen neuen Deploy, die eigenen Wiederholungen der CLI erzeugen dagegen nie ein Duplikat.

Erfolgreiche Deploys leiser machen

Bei einem ruhigen Projekt ist ein Push pro Deploy praktisch, bei einem viel beschäftigten zu viel. Statt die Pipeline zu ändern, legst du in der Web-App eine Regel für das Projekt an: Ist die Kategorie deployments und der Ereignistyp recovery, setz Mitteilungen auf Nur Zusammenfassung. Erfolge kommen dann gebündelt alle 15 Minuten, ein fehlgeschlagener Deploy wird weiterhin sofort gepusht.

Warum Entwarnungen statt einfacher Ereignisse

Ein einfaches Ereignis „Deploy erfolgreich“ würde jedes Mal in einer eigenen Gruppe landen. Ein fehlgeschlagener Deploy bliebe dann in „Wichtig“ offen, bis er einen Tag später inaktiv wird. Meldest du den Erfolg als Entwarnung für dieselbe Gruppe, schließt das den Fehlschlag, sobald die Korrektur live ist. Und der ganze Verlauf einer App und Umgebung bleibt an einem Ort.