Skip to Content
BlogTicketpilot-Release-Prozess

Wie Ticketpilot released wird: ein Tag, eine Pipeline und drei Agent-Skills

Martin MöllenbeckTicketpilotAgent Skillsrelease-processchangelogGitHub ActionsCuby

Ein Release von Ticketpilot ist am Ende genau ein Git-Tag. Alles davor — Version bestimmen, Changelog schreiben, package.json bumpen — erledigen Agent-Skills; alles danach — npm-Publish, Multi-Arch-Docker-Build, Registries — eine GitHub-Actions-Pipeline. Dieser Artikel zeigt beide Hälften: den automatisierten Weg zum Tag und den automatisierten Weg vom Tag zum fertigen Produkt.

Ein Produkt im Monorepo

Ticketpilot ist ein Cuby-Produkt-Plugin und lebt als Paket @processcube-io/ticketpilot im Monorepo ProcessCube.Products — zusammen mit den anderen Produkten. Das prägt den Release-Prozess: Versioniert wird pro Produkt, gebaut wird pro Release über eine gemeinsame Pipeline. Dafür gibt es zwei Arten von Tags:

TagBeispielZweck
Produkt-Tagticketpilot/v0.9.0-develop.91Versions-Marker pro Produkt — löst keinen Build aus
Release-Tagrelease/develop/4010a65Build-Trigger für die Pipeline (develop, insiders oder stable)

Eine neue Version wird nur in die package.json der Produkte eingetragen, die seit dem letzten Release tatsächlich Änderungen hatten — ändert sich die gemeinsame products-lib, zählen alle davon betroffenen Produkte dazu.

Der Weg zum Tag: drei Skills

Die Vorarbeit übernimmt der Skill release-process aus dem Marketplace-Repo ProcessCube.Agent.Skills  — installierbar mit einem Befehl:

npx skills add processcube-io/ProcessCube.Agent.Skills --skill release-process

/release-process — die Orchestrierung

Der Skill arbeitet im Single-Branch-Workflow (nur main): Branch prüfen, uncommittete Änderungen stashen, git pull. Dann leitet er die neue Version aus den Conventional Commits seit dem letzten Release ab — feat! bzw. BREAKING CHANGE heben MAJOR, feat MINOR, Fixes PATCH. Für die drei Release-Typen gilt:

TypFormatBasis
StableMAJOR.MINOR.PATCHCommits seit letztem Stable-Tag
InsidersX.Y+1.0-insiders.Nletzte Stable-Version, Minor +1
DevelopmentX.Y+1.0-develop.Nletzte Stable-Version, Minor +1

/changelog — der Pflichtschritt

Vor dem Versions-Bump ruft release-process verpflichtend den changelog-Skill auf. Der kategorisiert die Commits aus Anwendersicht (Neue Funktionen, Verbesserungen, Fehlerbehebungen, Technische Änderungen), ignoriert Merge-, Release- und WIP-Commits und pflegt zwei Dateien: Changelog.md für Anwender und Changelog-Dev.md für Entwickler. Features durchlaufen dabei die Phasen 🔮 In Entwicklung → 🧪 Insiders → ✅ Stable. Bei Ticketpilot liegt das Ergebnis unter products/Ticketpilot/Changelog.md — und erscheint automatisch in den Release Notes.

Bump, Commit, Tags

Zum Schluss bumpt der Skill die package.json, committet (chore: release v{VERSION}) und setzt die Tags. Wichtig im Monorepo: Das Release-Tag wird immer allein gepusht, damit der GitHub-Build sauber startet.

Flankierend: die Doku-Pipeline

Rund um den Release halten repo-doku (Quell-Repo) und doku-uebernehmen (Doku-Site) die Dokumentation mit dem Code Schritt — das Zusammenspiel zeigt Dokumentation als Pipeline.

Warum Skills statt Shell-Skript? Die Versionslogik ist keine starre Regel-Kaskade: Commits kategorisieren, Anwender-Changelog formulieren, entscheiden, welche Pakete betroffen sind — das sind Aufgaben, bei denen ein Agent den Kontext versteht. Der Skill gibt ihm dafür den festen Rahmen, damit jedes Release gleich abläuft.

Der Weg vom Tag: die Pipeline

Das gepushte release/…-Tag triggert den Workflow Release Build & Publish (.github/workflows/publish.yml):

Drei Jobs, drei Aufgaben:

  1. publish — publiziert erst die products-lib, dann alle Produkt-Pakete nach GitHub Packages. Ein Idempotenz-Check (npm view) überspringt bereits veröffentlichte Versionen — der Workflow ist gefahrlos wiederholbar.
  2. build-ticketpilot — baut das Image processcube_lowcode_ticketpilot als Matrix-Build nativ auf amd64- und arm64-Runnern, gepusht by digest. Die Version kommt direkt aus der package.json des Produkts.
  3. merge-ticketpilot — fügt die Digests per docker buildx imagetools zu einer Multi-Arch-Manifest-Liste zusammen und taggt :{VERSION} und :latest.

Am Ende steht das Image in der GHCR und im ProcessCube® Marketplace — von dort installiert Cuby das Produkt.

Die Pointe: Ticketpilot released sich selbst

Ticketpilot automatisiert Ticket-Workflows — und seit 0.9.0-develop.87 gehört dazu auch der eigene Release-Auslöser: Der mitgelieferte BPMN-Prozess „Ticket releasen” stößt für Feature- und Bug-Tickets automatisch ein Insiders-Release des Kundenprojekts an. Technisch ist das ein External Task (Topic InsiderReleaseErstellen), den ein DevOps-Agent abarbeitet, während ein Build-Watcher den Fortschritt überwacht — also genau der Mechanismus, den der vorige Artikel im Detail zeigt. Der Release-Prozess, den dieses Produkt seinen Nutzern abnimmt, ist derselbe, mit dem es selbst gebaut wird.

Fazit

Ein Ticketpilot-Release besteht aus zwei sauber getrennten Hälften: Die Skills (release-process, changelog, flankierend repo-doku) erledigen die Denk- und Schreibarbeit bis zum Tag — reproduzierbar und mit gepflegtem Changelog. Die Pipeline übernimmt ab dem Tag — idempotenter npm-Publish und Multi-Arch-Images in beide Registries. Für das Team bleibt: Commits nach Conventional-Commits-Format schreiben und /release-process aufrufen.

Weiterführend

Knowledge-Wiki (Karpathy & OKF)Agenten als External Task