Zum Hauptinhalt springen

Azure Boards

Azure Boards ist der Work-Item-Tracker von Microsoft und Teil von Azure DevOps Services. Work Items werden innerhalb eines Projekts über eine fortlaufende numerische ID (#12345) angesprochen, in Commit-Nachrichten oft mit dem Präfix AB#, um sie von Issue-Verweisen im GitHub-Stil zu unterscheiden.

Forgejo-Seite: externer Issue-Tracker

Repository → Einstellungen → Einheiten → Issues → Externen Issue-Tracker verwenden.

FeldWert
External issue tracker URLhttps://dev.azure.com/<your-org>/<your-project>/_workitems/edit/{index}
External issue tracker URL formathttps://dev.azure.com/<your-org>/<your-project>/_workitems/edit/{index}
External issue tracker number formatRegexp
External issue tracker number format regexp`(?:AB

Der reguläre Ausdruck erfasst sowohl AB#12345 (den kanonischen Verweis in Azure Boards) als auch die ältere Form #12345. Ersetze <your-org> und <your-project> durch die Slugs deiner Azure-DevOps-Organisation und deines Projekts.

Empfohlenes Format für Commit-Nachrichten

refactor: extract token-exchange path

AB#34521

Das Präfix AB# ist eine lose Konvention aus der Dokumentation des Azure-DevOps-Teams. Verwendet dein Team stattdessen ein bloßes #12345, erfasst der reguläre Ausdruck oben beides – beide Schreibweisen in einem Repository zu mischen, verwirrt aber nachgelagerte Werkzeuge.

Tracker-Seite: Service Hooks (optional)

Damit Azure Boards die verknüpften Commits und PRs an jedem Work Item anzeigt:

  1. Azure DevOps → Project Settings → Service hooks → + Add subscription.
  2. Dienst: Web Hooks (die letzte Option in der Liste – Azure bringt keinen nativen Service Hook für „Forgejo“ mit, aber Web Hooks akzeptiert jede URL).
  3. Auslöser: Belasse ihn auf „Code pushed“ oder „Pull request created“, je nachdem, was angezeigt werden soll.
  4. URL: Lege in fremforge ZUERST einen ausgehenden Webhook an (Admin → Webhooks → Add Webhook) mit dem Ziel https://dev.azure.com/<your-org>/<your-project>/_apis/git/repositories/<your-repo-id>/links – dem Endpunkt von Azure zum Anhängen von Links. Füge diese URL in das Service-Hook-Abonnement ein.

Der Weg ist asymmetrisch (Forgejo → Azure), weil Azure DevOps externe Repositorys für Forgejo nicht abfragt; es erwartet Pushes, die von deiner CI oder deinem Code-Host gemeldet werden. Der ausgehende Webhook von fremforge ist dafür der richtige Baustein.

Folgen für Unterauftragsverarbeiter

Die Steuerungsebene von Azure DevOps Services ist Microsoft Azure (Regionen US-Central und EU-West, je nach Datenresidenz). Wenn du fremforge mit Azure Boards verbindest:

  • Commit-Metadaten und Repository-Verweise fließen zu Microsoft Azure.
  • Nimm Microsoft Corporation als Verarbeiter personenbezogener Daten (E-Mail-Adresse der Commit-Autorin oder des Commit-Autors, Commit-Nachricht) in dein Verzeichnis der Unterauftragsverarbeiter auf.
  • Der AVV von fremforge schließt Unterauftragsverarbeiter von Microsoft ausdrücklich aus (gemäß der Souveränitätsausrichtung auf der Trust-Seite); für diese Strecke steht der AVV-Nachtrag deines Tenants für sich.

Für souveränitätskritische Workloads kommt Plane (selbst gehostet, in der EU betreibbar, Apache 2.0) als Alternative zu Azure Boards in Frage.

Was das nicht leistet

  • Kein automatisches Schließen beim Merge (Azure Boards unterstützt Automatisierung über Work Item Automation rules; richte die Regel auf Basis der Payload des eingehenden Web Hooks ein).
  • Die native Integration von Azure DevOps Repos (Statusübergang beim PR-Merge) lässt sich NICHT auf Forgejo übertragen – diese Verknüpfung gibt es nur in Repos. Die fremforge-Integration ist einseitig (Commit/PR → Link zum Work Item), dazu kommt kundenseitige Automatisierung für die Gegenrichtung.
  • Die Synchronisierung von Sprints, Iterationen und Bereichspfaden gehört nicht zum Umfang. Das sind Azure-interne Konzepte, die sich nicht sauber auf einen Git-Host abbilden lassen.
Jira Data CenterLinear