Pull Requests und Pipelines am Ticket. Der Code bleibt im Repo.
Spedy hängt sich an GitHub, GitLab oder Bitbucket. Commits und Pull Requests landen automatisch am richtigen Ticket, alle offenen PRs eurer Kundenprojekte stehen in einer Ansicht, und Pipelines laufen sichtbar daneben mit.
- NORD-214 Cache für Produktliste · #143Review offen
- KESS-91 Rechnungsexport CSV · !58Pipeline läuft
- VITA-40 Fix Login-Redirect · #77Änderungen angefragt
- BRAN-12 Footer-Links · #31gemergt
Drei Anbieter, ein Repo pro Projekt oder mehrere.
GitHub als GitHub App oder per Token, GitLab als gitlab.com oder eigene Instanz über https, Bitbucket Cloud per API-Token. Pro Projekt verknüpft ihr die passenden Repositories; den Webhook richtet Spedy selbst ein.
- Commits am Ticket
- Steht der Ticket-Schlüssel in der Commit-Nachricht (NORD-214), erscheint der Commit im Code-Bereich des Tickets.
- Pull Requests am Ticket
- Steht der Schlüssel im Branch-Namen oder PR-Titel, wird der PR bzw. Merge Request verknüpft.
- feat(NORD-214): cache product listCommit
- NORD-214 add cache invalidationCommit
- PR #143 nord-214-product-cacheoffen
Alle PRs und Pipelines aus allen Projekten.
Die Pull-Request-Ansicht zeigt PRs und Merge Requests aller drei Anbieter zusammen und aktualisiert sich live. Die Pipeline-Ansicht zeigt Läufe von GitHub Actions und GitLab CI, auch ohne PR, etwa auf dem Hauptbranch.
- PR-Detail
- Reviews mit Status, die Schritte der letzten CI-Ausführung, Commit-Anzahl, Verlauf und ein Link zum Anbieter.
- Auch für Agenten
- Per MCP lesen Agenten PRs und Pipelines und sehen im Lieferverlauf eines Tickets Branch, PR, Reviews, Merge und CI.
- nordwind-shop · main · build → test → deployläuft 04:12
- kessler-portal · !58 · lint, testerfolgreich
- vitalis-app · #77 · e2efehlgeschlagen
Vorschläge statt stiller Statuswechsel.
Erkennt Spedy einen Commit, einen geöffneten oder gemergten PR, angefragte Änderungen oder ein vollständiges Approval, schlägt es einen Statuswechsel vor. Ein Mensch nimmt ihn an oder verwirft ihn, einzeln oder gesammelt.
- Pro Projekt einstellbar
- Auslöser einzeln an- oder abschalten und den Zielstatus festlegen, zum Beispiel „PR gemergt → Im Review beim Kunden“.
- Jeder Wechsel mit Grund
- Spedy protokolliert, ob ein Status manuell, durch einen angenommenen Vorschlag oder durch das System geändert wurde.
Was es nicht kann
Damit es in der Demo keine Überraschung gibt.
- Keine Bitbucket-Pipelines: Von Bitbucket kommen PRs und Commits, aber keine CI-Status.
- Keine anderen CI-Systeme (Jenkins, CircleCI, Azure DevOps) und keine anderen Git-Hosts (Azure Repos, Gitea, Bitbucket Server).
- In Spedy wird nichts gemergt, approved oder kommentiert: Die PR-Ansichten lesen nur und verlinken zum Anbieter. Keine Diff-Ansicht, kein Code-Browser.
Häufige Fragen
- Müssen Entwickler etwas anders machen?
- Nur den Ticket-Schlüssel in Commit-Nachricht, Branch-Name oder PR-Titel schreiben. Den Branch-Namen schlägt Spedy beim Übergeben an ein Coding-Tool schon mit vor.
- Sehen Kunden unsere PRs und Commits?
- Nein. Code-Aktivität ist für Kunden nicht sichtbar.
- Funktioniert unsere eigene GitLab-Instanz?
- Ja, wenn sie per https erreichbar ist. Interne Adressen ohne öffentlichen Zugang gehen nicht.
- Können wir aus Spedy heraus neue Repositories anlegen?
- Ja, beim Anlegen eines Projekts: aus einer Vorlage (GitHub oder GitLab), als neues GitHub-Repo mit Startdateien oder durch Verknüpfen eines bestehenden Repos bei GitHub oder GitLab.
Sprechen wir über eure Arbeitsweise.
Spedy gibt es nur über einen Demo-Call. Fragt eine Demo an oder bucht direkt einen Termin.