CI/CD-Deploys

Q: Wie benachrichtige ich mein Team über einen abgeschlossenen Deploy?

Mit einem curl -Schritt am Ende des CI-Jobs, der an /api/push/send postet. Jeder Runner, der HTTP sprechen kann, genügt. Das Team bekommt die Meldung in Echtzeit aufs Handy, ohne die Pipeline im Blick behalten zu müssen.

Q: Wie unterscheide ich erfolgreiche von fehlgeschlagenen Builds?

Setze den Benachrichtigungs-Schritt auf always, damit er auch nach einem Fehlschlag läuft, und übergib den Job-Status im Titel. Für fehlgeschlagene Builds lohnt sich zusätzlich "urgent": true, damit die Meldung auch in einer Ruhezeit sofort ankommt.

Q: Wie trenne ich Staging und Produktion?

Über eigene Kanäle, etwa deploys-staging und deploys-prod. Mit API-Key-Scopes darf ein CI-Schlüssel dann nur in den für ihn vorgesehenen Kanal schreiben.

Q: Kann ich Zustell-Ereignisse in mein eigenes System zurückspielen?

Ja, über Webhooks. PushPig ruft dann bei push.sent oder push.failed eine URL in deiner Infrastruktur auf, HMAC-signiert und mit stabiler Delivery-ID über alle Wiederholungen.

Dein Team automatisch informieren, wenn ein Build oder Deploy durch ist.

Kein ständiges Starren auf die Pipeline mehr: Mit PushPig benachrichtigt deine CI/CD das Team automatisch, sobald ein Build oder ein Deployment fertig ist oder fehlschlägt. Ein HTTP-Request am Ende des Jobs reicht.

In die Pipeline einbauen

Ob GitHub Actions, GitLab CI, Jenkins oder ein Shell-Deploy-Skript. Jeder Runner, der curl kann, kann senden:

- name: Notify PushPig
  if: always()
  run: |
    curl -X POST https://pushpig.de/api/push/send \
      -H "Authorization: Bearer pp_DEIN_API_KEY" \
      -H "Content-Type: application/json" \
      -d "{\"channel\":\"deploys\",\"title\":\"Deploy ${{ job.status }}\",\"body\":\"${{ github.repository }} @ ${{ github.sha }}\"}"

Erfolg und Fehler unterscheiden

Setze den Job auf always und übergib den Status im Titel, so weißt du auf einen Blick, ob der Deploy durch ist oder Aufmerksamkeit braucht. Für fehlgeschlagene Builds lohnt sich "urgent": true, damit die Meldung auch in einer Ruhezeit sofort ankommt.

Ein Kanal pro Umgebung

Trenne deploys-staging und deploys-prod in eigene Channels. Über API-Key-Scopes darf ein CI-Key dann z. B. nur in den Produktions-Kanal schreiben, sauber getrennt und abgesichert.

Wiederkehrende Meldungen als Vorlage speichern und in der Pipeline nur noch die Variablen (Version, Umgebung) befüllen: konsistente Deploy-Nachrichten ohne Copy-&-Paste.

Und andersherum

Du willst PushPig-Events in dein eigenes System zurückspielen? Über Webhooks bekommst du HMAC-signierte Zustell-Ereignisse (push.sent, push.failed) direkt in deine Infrastruktur.

Häufige Fragen

Wie benachrichtige ich mein Team über einen abgeschlossenen Deploy?

Mit einem curl-Schritt am Ende des CI-Jobs, der an /api/push/send postet. Jeder Runner, der HTTP sprechen kann, genügt. Das Team bekommt die Meldung in Echtzeit aufs Handy, ohne die Pipeline im Blick behalten zu müssen.

Funktioniert das mit GitHub Actions, GitLab CI und Jenkins?

Ja, mit allen dreien und mit jedem Shell-Deploy-Skript. Es wird kein Plugin und keine Integration gebraucht, nur ein HTTP-Request mit dem API-Schlüssel im Authorization-Header.

Wie unterscheide ich erfolgreiche von fehlgeschlagenen Builds?

Setze den Benachrichtigungs-Schritt auf always, damit er auch nach einem Fehlschlag läuft, und übergib den Job-Status im Titel. Für fehlgeschlagene Builds lohnt sich zusätzlich "urgent": true, damit die Meldung auch in einer Ruhezeit sofort ankommt.

Wie trenne ich Staging und Produktion?

Über eigene Kanäle, etwa deploys-staging und deploys-prod. Mit API-Key-Scopes darf ein CI-Schlüssel dann nur in den für ihn vorgesehenen Kanal schreiben.

Kann ich Zustell-Ereignisse in mein eigenes System zurückspielen?

Ja, über Webhooks. PushPig ruft dann bei push.sent oder push.failed eine URL in deiner Infrastruktur auf, HMAC-signiert und mit stabiler Delivery-ID über alle Wiederholungen.

Hilfe & API · Preise · Kontakt · Impressum · Datenschutz