Notificări de deploy din orice CI

Majoritatea sistemelor de CI te anunță când un pipeline eșuează. Un deploy e altceva: e momentul în care se schimbă producția, iar despre el vrei să afli oriunde ai fi, cu eșecurile anunțate tare și succesele, discret. CLI-ul honk-me face asta în orice runner care poate rula un binar.

Modelul e același peste tot. Un deploy eșuat e o problemă în grupul deploy/<app>/<environment>. Un deploy reușit e o revenire în același grup: după un eșec, închide incidentul, iar după un deploy bun îți spune doar că a mers.

Înainte să începi

Un cont Honk (deocamdată, doar pe bază de invitație: cere acces) și un proiect pentru deploy-uri, cu o cheie API.
HONK_URL și HONK_KEY ca secrete în CI.
CLI-ul honk-me în imaginea de deploy: go install github.com/honk-me/honk-go/cmd/honk-me@latest sau un binar de pe pagina Releases.

Un script de deploy

Dacă faci deploy cu un script, un trap raportează orice linie care eșuează, iar ultima linie raportează succesul:

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

Cheia de idempotență e formată din aplicație și revizie, deci același deploy rulat de două ori e raportat o singură dată.

GitLab CI

after_script rulează după job, indiferent dacă a trecut sau a eșuat, iar CI_JOB_STATUS îți spune cum s-a terminat:

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() rulează pasul în orice caz, iar job.status îți spune cum a mers jobul până acolo:

      - 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

Cheia de idempotență include numărul încercării: un Re-run e raportat ca deploy nou, iar reîncercările făcute de CLI nu dublează niciodată un deploy.

Deploy-uri reușite, mai discrete

O notificare pentru fiecare deploy e utilă pe un proiect liniștit, dar e prea mult pe unul aglomerat. Nu trebuie să schimbi pipeline-ul: adaugă o regulă în proiect, din aplicația web. Când categoria este deployments și tipul evenimentului este recovery, la Notificări alegi Doar în rezumat. Deploy-urile reușite vin apoi adunate la fiecare 15 minute, iar unul eșuat te anunță în continuare imediat.

De ce reveniri și nu evenimente simple

Un simplu eveniment „Deploy reușit” ar ajunge de fiecare dată în alt grup, iar un deploy eșuat ar rămâne în Atenție până ar deveni inactiv, o zi mai târziu. Dacă raportezi succesul ca revenire în grupul deploy-ului, eșecul se închide în clipa în care corecția ajunge în producție, iar tot istoricul unei aplicații într-un mediu stă într-un singur loc.

Deocamdată, Honk e disponibil doar pe bază de invitație: cere acces. Tot ce face acest ghid merge și pe planul Free.